On 5/19/2010 9:17 AM, none wrote:
Victor Bazarov wrote:
On 5/19/2010 8:57 AM, none wrote:
I have a large application which is around 8 MB when its build. I am
pretty sure there are some unnecessary includes. Is there some tool to
locate large or unused header files in soure code?
Uh... I read somewhere that there was a tool for weeding out the
includes that weren't used, and GIYF for that. However, do consider
that usually headers contain *declarations* which usually are only
used by the compiler and do not get converted into code (that's the
*definition's* job).
Ask your linker to produce a *map* file and examine it. You're going
to find what libraries you have linked to, and what modules functions
you have defined.
Also, consider that 8MB is *not* a large application. A large
application would be on the scale of *hundreds* of megabytes with a
multitude of modules it loads at run time.
V
My application is primary based on template classes and use headers from
a a template library so all the hard work is done a compile time.
So why are you so concerned with how long it takes to compile it? The
hard work needs to be done some time, no?
It takes more than a 1 minute to compile the application (resulting in
the 8 MB executable) which I think is a long time to wait if I just do
small changes.
There are changes and there are changes. There are also ways to
eliminate the compile-time dependencies which usually speeds up
compilation (but no guarantees). PImpl is one. Using
forward-declarations of most classes in the headers instead of pulling
the "needed" headers is the other.
> I have tried to move out some of the classes (which
removes the core functionality of the application) and then the compile
time is lowered significantly.
Not sure what you mean by "moving out" of classes, but if it's critical
to your application, what purpose would moving out serve? You can try
to identify which ones are contributing the most to the compilation time
and the app size, and work on those, but don't expect miracles. If your
app needs its functionality, you gotta keep the classes, no? And you
need to compile those at some point...
Is there any way to optimize the compile time with all the functionality
or is this just something I have to accept?
I already mentioned a couple of ways. The main motif here is to
separate the implementation from the interface. If you can move the
definitions of your member functions from headers into separate C++
source files, do. Also, compartmentalize your code, if you're working
on some part, others shouldn't have to be recompiled. For example, in
our shop we have a policy of "one class per module". It's not always
observed, but it does help to reduce the number of files you touch when
you need to change the implementation (not the definition) of a class.
when I merge some files. Doing that has an affect on build times,