Dirk Reiners wrote:
Hi Marcus,
On Tue, 2006-04-11 at 15:24 +0200, Marcus Lindblom wrote:
[snip]
one could probably improve build times for the
full-builds by:
- combining the cpp-files into larger files (say 20-50 or so).
Well, that's not really a good option. It might help when you have to
recompile from scratch, for incremental compiles that will hurt quite a
bit.
Yup. It was more thought of as an option when doing full builds. I've
also found, for my project, that small cpp files (below 1-2k) compiles
equally fast (unless they generate lots of code via templates/macros) so
I tend to combine those into single files (a few such 'smallclasses.cpp'
per source-dir or so).
One thing to look at (if possible with the make tools) might be to
invoke the compiler once for several cpp's, as Visual Studio does. That
would perhaps reduce some overhead, although I suspect most of the time
is just fetching/parsing header files.
- copying all headers to one directory (less searching).
I know other systems do that, but I hate it. I think the header belongs
as close the source file as possible, which is in the same directory.
I agree, of course, being very fond of order & structure (you ought to
have guessed that by now, right? :). But with scons or something you
could perhaps copy the headers to a single 'header-cache' dir before
compiling. It's not pretty, but it might help a bit.
I wish someone would invent a better way of compiling c++. It's a nice
language, but the physical process of getting a runnable from source is
a bit trying at times. :-/
Actually, I'm planning on throwing swig at our project sometime this
year, which should be an indication on how difficult it is be to
swig-wrap OpenSG to Java (most likely we'll use Java+Jython to script).
We want to reduce our amount of c++ as much as possible, since it takes
too much time to recompile when developing here (most of our classes has
xml-bindings similar to Boost-Python, which is a lot of template code).
The install does copy all of them together, but that doesn't help for
compiling the libs.
Yup. That is nice.
- start to use precompiled-headers (for system files and for the
Base-headers when compiling the other libs).
That's a definite that I really want to do with 2.
Indeed. I should try to find the time to write a script that does this
automatically (and wraps it in #ifdef XXX_USE_PCH ...). I need this for
our project as well.
I've found that with PCH's, compilation time is to a quite large extent
proportional to the size of the PCH, rather than the size of the cpp and
it's includes. Therefore, there are even larger gains of combining
source files when using PCH's.(at least with big PCH's, such as the one
we have which has a lot of OpenSG code, it's around 80 mb and needs to
be read for each invocation of the compiler. Having 2 gb of mem is nice
when compiling/linking the ~400 mb of object files that we get. :)
If I ever get some time to improve on OpenSG, I will definitely look at
this.
Some other experiences we found for speeding up compiling on Windows:
- never ever try to compile on a network drive. SMB is incredibly slow.
Got that one covered. Actually I'm using a mirrored RAID system, so
reading should be a bit faster. However, since we don't use PCH's, there
is little gained by having more throughput.
- if you're using the McAffee virus scanner, stop it. Not just
deactivate, it has to be stopped and out of the system. Apparently the
scanner takes quite a while every time a program starts, and with make
there are thousands of program/script starts.
We're using F-secure, which is not much better, but I've disabled it so
that it doesn't scan the ms-compiler nor the build-directories.
Concerning the .pdb files: I just added a little bit of code to the
dailybuild that will add them to the binary snapshots. They're in a
separate directory called pdb. Should be in tomorrow's dailybuilds.
Ah! Great! Thanks a lot!
Best Regards
/Marcus
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
