Re: Source of EXE Size OT
- From: "Ralph" <nt_consulting64@xxxxxxxxx>
- Date: Tue, 13 Sep 2005 10:30:24 -0500
"Duane Bozarth" <dpbozarth@xxxxxxxxxxxx> wrote in message
news:4326E653.5B6BCDF1@xxxxxxxxxxxxxxx
> Dan Johnson wrote:
> >
> > To answer both Chris and your questions...
> >
> > > > My VB6 executable file has significantly increased in size ....
> > >
> > > Since when?
> >
> > ***Over the last several months it's gone from approx. 1,900 KB to 3,800
KB.
> >
> > >
> > > > ...and I'm having a
> > > > difficult time figuring out where the increase is coming from.
> > >
> > > What you added/changed since the above???
> >
> > ***Lots of changes. Primarily have switched to using CodeJock interface
> > controls. Although the CodeJock controls did not seem to increse the
file
> > size much when I first started using them.
>
> That's the way w/ Big Mac's and fries, too... :)
>
> > > I think I'd concentrate on the first question, though, followed by
> > > "what's the problem?" Is load time excessive, are you running out of
> > > memory, just curious, ... ?
> >
> > ***None of the above really. Have always kind of monitored the size of
the
> > executable, with the assumption being that the smaller the better. No
> > specific problems noted right now, but if there was a simple way to
> > determine what caused an increase in the size of the file, and it's easy
> > enough to make a change to decrease the size, wouldn't it generally be a
> > good idea to do so?
> >
> > Thanks for any feedback.
>
> I suspect the answer to the original question is in your first response
> above.
>
> My question was based on an assumption you wouldn't have thought the
> .exe had "significantly" increased in size unless there had been a
> sizable change w/ what had seemed to be an insignificant change in code
> functionality or other modification. I suspect if you could roll back
> and generate a plot of code size vs build you would find it a much more
> gradual effect of simply adding features.
>
> There is, of course, the possibility this particular set of controls is
> more memory intensive than some other set of coders could have provided
> the same or similar functionality. Since I don't know of it/them can't,
> obviously, comment on them specifically.
>
> Regarding the last comment, it is good as a general idea to try to
> contain code bloat, yes. However, one of the features of a language
> like VB is that you may acrifice control over <how> things are done in
> order to use the facilities provided by the language and associated
> add-ons. If you want/need the functionality of the 3rd party controls,
> then you have to pay the fiddler, so to speak.
If you all don't mind I would like to piggy-back on this thread and ask a
question.
There is a phenomena in VB6 when compiling to native code the exe will grow
by a small amount with each compile, even if there has been NO change in
code. The solution is generally to close the project, cleanout the files and
go again. So there is no long lasting harm.
But I have been curious all these years - has anyone ever come up with an
explanation of where those extra bytes are coming from. I have occasionally
googled, but never found anything but the complaints, never an answer. Doing
a compare on the exe appears to show a growth in both .text and .data (tho
seldom equal).
Just curious.
-ralph
.
- Follow-Ups:
- Re: Source of EXE Size OT
- From: Duane Bozarth
- Re: Source of EXE Size OT
- References:
- Source of EXE Size
- From: Dan Johnson
- Re: Source of EXE Size
- From: Duane Bozarth
- Re: Source of EXE Size
- From: Dan Johnson
- Re: Source of EXE Size
- From: Duane Bozarth
- Source of EXE Size
- Prev by Date: Re: 438 - Object doesn't support this property or method
- Next by Date: Re: Check if a form is loaded
- Previous by thread: Re: Source of EXE Size
- Next by thread: Re: Source of EXE Size OT
- Index(es):
Relevant Pages
|
