On Apr 25, 10:13 am, bor...@[EMAIL PROTECTED]
wrote:
> Hi all,
>
> to reduce the build-time of our project we use following trick:
>
> Instead of compiling each CPP and linking together, we auto-generate a
> CPP which includes all CPP of the project and compile only this one.
> The effect is that the compiler has to compile each involved header
> only once opposed to a per-cpp-file basis.
This will probably speed things up on a single processor machine when
you need to rebuild the entire project since you won't instantiate the
same template multiple times only to have the linker delete all, but
one copy. However, there are better ways to speed things up, and your
approach will break things (as I mention later). Also, 90% of the time
your approach will actually be *slower*. This is because, every time
one of those files is updated, the *entire* project will be rebuilt
under your schema. So you really only get a performance gain after a
checkout, and not when recompiling after editing individual files,
which would normally only require you to recompile that specific cpp
file and relink it.
Instead, your build process can be multithreaded. Both make and visual
studios 9 sup****t this out of the box. Or better yet, you can use
distcc or similar process and have your build done on a cluster.
In each of these cases there is some duplication of effort over your
approach, since templates are multiply instantiated, so the total
processing is higher. However, no one cares about the total cycles
spent, only on the latency between hitting compile, and getting your
executable back, and this latency will decrease under a parallelized
setup better than using your trick to avoid multiple instantiations.
Parallelization (especially with a distributed mechanism like distcc)
will scale up and give you performance benefits on much larger code
bases.
I've used a distcc like mechanism before for compiling a fairly
enormous code base, and while there was some time spent moving stuff
across the network, the total compilation time went done by quite a
bit, and actually became manageable. If you sup****t both local and
distributed builds, than the developer can use the distributed build
after a huge checkout to quickly get the project compiled, and then
use the local build after each small file update to rebuild individual
modules without the network latency.
>
> The question is: once it compiled successfully (no duplicate
> definitions etc), is there any side-effect possible? Is the linked
> library/executable any different than the one produced the 'normal'
> way?
Yes! In fact, I'm surprised all of your code didn't break immediately.
Static variables and the contents of anonymous name spaces are only
accessible in the translation unit in which they are defined. e.g.
// all this stuff should only be accessible from each individual cpp
file:
static int s_my_int = 0;
namespace {
int another_int = 0;
class my_class {};
}
Your technique essentially concatenates all cpp files together so you
only have one translation unit. All of these static and anonymous name
will effectively end up in the global namespace. You will eventually
run into multiple definitions of the same thing. e.g.
// one.cpp
namespace {
void helper_fun() {
}
}
// two.cpp
namespace {
// should fail to compile.
void helper_fun() {
}
}
>
> There is one issue I already can think of: the order of the execution
> of constructors of static objects (like global variables). Any more?
Well, the order of execution of static objects is normally not defined
across translation units. You are actually taking something defined
and making it defined by putting everything in a single translation
unit. I can't imagine how this would be harmful, except that you might
come to depend on the order of instantiation which would go away if
you changed back to the multiple translation unit model.
The real problem is you are munging all of the anonymous namespaces
and statics together into a single translation unit.
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
