Re: Compilation speed on Windows (was: Re: GTK+ for Windows MSVCRT dependency?)

[Robert Ögren <gtk roboros com>]

On Mon, 7 Mar 2005, Morten Welinder wrote:

> I'll stick my neck out and guess that this is caused by the
> ill-executed gtkalias.h hack.
>
> Basically, any file that uses any gtk header will depend on
> every single gtk header file.  And that's a lot.

Nope, the improvements my mail talked about was about reducing time spent
outside gcc. For example, on my machine:

Without libtool-cache:
make gtklabel.lo  takes 5.6 s
make libgtk-win32-2.0.la  takes 40 s

With libtool-cache:
make gtklabel.lo  takes 1.8 s
make libgtk-win32-2.0.la  takes 3.4 s

Each command was run several times so the system disk cache and
libtool-cache's databases were populated. And of course I removed the
.lo/.la file before rerunning make :)

Since there are about 200 source files in the gtk subdirectory alone, this
gives about 10 minutes shorter compile time just for that directory when
doing a full rebuild of GTK+ on my machine.

The cached link commands significantly shortens a full rebuild (if the
cache is already populated), but is also very nice when you are working on
one source file and need to relink libgdk or libgtk many times.

The deal with /usr/bin/install is a minor thing, but it seems that
Windows refreshes the start menu etc. each time a program named "install"
or "setup" finishes executing, which consumes unnecessary CPU when
/usr/bin/install is run 100's of times for all message files and header
files. This only shaves a few minutes off the time from a full "make
install" of GTK+, but I thought someone would find it amusing.

Replacing the ~1MB large gtkalias.h with an empty file seems to give about
0.02 s reduction in compile time for gtklabel. The visibility attribute is
not supported on win32 (at least not with the gcc I'm using) so the entire
file is ifdef:ed away.


Robert