[omniORB] Generating seperate stubs for structs and sequences

[Mike Mascari]

baileyk at schneider.com wrote:

> I'm not convinced that splitting up IDL files into many small files is
> going to save you compile time.  I haven't done detailed analysis, but I
> suspect that the biggest compile time overhead is swallowing the ORB
> headers themselves (template declarations, etc..), and not the headers
> coming out of the IDL compiler.  By splitting up your IDL you will have to
> manage many more source files (and dependencies) and may not see compile
> times improve much if at all.  Reducing C++ compile time is probably best
> tackled by throwing more hardware at it.  Is there any way to distribute
> your C++ compiles to multiple CPUs/machines?  

That's a possibility. We have some extra machines all running the 
same OS, same architecture (RedHat 8.0/x86).

> I'm just afraid you are
> signing up for many many more man hours of work in the long run to save a
> little cpu time.  A better bargain might be to buy more/faster hardware to
> do compiles on.

That can't hurt! What's interesting is that the same omniidl 
generated header is imported into stdafx.h on a client-side 
application. And Microsoft's precompiled header handling allows for 
that application to perform a complete rebuild in about 35 minutes.

The client-side MFC application is just a little less than the 
server-side in terms of k-lines of code *and* includes the MFC 
headers. That's why I tried the latest g++ 3.4 snapshot to see if 
its precompiled header handling might reduce compilation time 
equivalently (or less, since there aren't any MFC headers to include 
on the server-side). It halved the time to about an hour, but it 
still seems unreasonably long. Total code, not including the 
C++-generated stubs is only around 80,000 lines. I even tried 
Intel's new 8.0 compiler which recently added precompiled header 
support. It just segfaults consistently....

I'll pull out a few into separate IDLs and compare the individual 
compile times to see what kind of a percentage gain I get. If it's 
not more than 10% I won't bother pursuing it. But I'm an eternal 
optimist...

Mike Mascari

>>On Tuesday 10 February, Mike Mascari wrote:
> 
> Okay. I'll change it to generate individual IDLs. I was hoping there
> was a backend switch I was missing. Is there an equivalent to 'cc
> -M' that I should be aware of? How do people handle inter-IDL file
> depedency generation? Or is it an issue in 99% of the cases?
> 
> Mike Mascari