Re: Source of EXE Size

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.
.

Relevant Pages

  • Re: OOP style
    ... >> The root of all evil, if not avoided, is putting functionality ... becomes enabled when you change anything in one of the dialog's controls. ... There is also an extra property "Dirty", ... That event dispatcher enables or ...
    (comp.lang.pascal.delphi.misc)
  • Re: RADiest Client for SQL Server
    ... > So were they MDB front ends or ADP front ends? ... Access starts off with all functionality and you have to find ways to ... The controls look like real windows controls, ... probably need to purchase Active Reports or Crystal Reports to have ...
    (microsoft.public.sqlserver.server)
  • Re: RADiest Client for SQL Server
    ... > So were they MDB front ends or ADP front ends? ... Access starts off with all functionality and you have to find ways to ... The controls look like real windows controls, ... probably need to purchase Active Reports or Crystal Reports to have ...
    (microsoft.public.sqlserver.programming)
  • Re: RADiest Client for SQL Server
    ... > So were they MDB front ends or ADP front ends? ... Access starts off with all functionality and you have to find ways to ... The controls look like real windows controls, ... probably need to purchase Active Reports or Crystal Reports to have ...
    (microsoft.public.sqlserver.clients)
  • Re: RADiest Client for SQL Server
    ... > So were they MDB front ends or ADP front ends? ... Access starts off with all functionality and you have to find ways to ... The controls look like real windows controls, ... probably need to purchase Active Reports or Crystal Reports to have ...
    (microsoft.public.sqlserver)