Re: Performance issues with Cons

The performance penalty is the cost of correctness. Cons is analyzing 
every dependency before it does anything. So, you can avoid it by trimming 
dependencies. That's what we do. This is the technique that a developer 
will use when developing their code. For integration builds, you then let 
Cons evaluate all dependenices to make sure you haven't broken anything. 
Sure, gnu-make might start working right away, but most people do not 
write their make files correctly so gnu-make is not evaluating all 
dependencies. There is a paper regarding recursive make that discusses the 
issues. Not only that, but gnu-make is a half-assed script language, where 
perl is not. There isn't any problem that cannot be solved with perl. You 
might find the scripting capabilities of gnu-make lacking. We looked at 
using gnu-make, but we got our Cons prototype working so quickly we 
abandoned the thought.

David





[email protected]
Sent by: [email protected]
10/02/2002 08:45 AM

 
        To:     [email protected]
        cc:     (bcc: David Weidenkopf/ATL-BTL/MS/PHILIPS)
        Subject:        Performance issues with Cons
        Classification: 






Hi all,

I don't know if anyone else is seeing this, but we're finding that cons is
pretty slow...  We've got a moderately sized project (currently generating 
about
2500 object files, from a mixture of C and C++ source files), and it's 
taking
something like 15-20 seconds for cons to actually start compiling any 
files, on
a pretty zippy dual UltraSparc-III - 900Mhz, I think...

Now, our include heirachy is pretty bad - a lot of source files include a 
lot
more header files than they really need to...  So I assume that most of 
that
time is spent building up and checking the dependancies...  I'm hoping to 
fix
the include heirarchy, but it's not going to be a quick thing, and I'm not
positive how much that's going to speed up cons...

Has anyone done any work on improving this?  I haven't spent much time 
looking
at the code inside cons, so I don't know if the code itself could be made 
more
effiicient, but it seems like it should be possible to cache the include
dependancies somewhere, and only rebuild them when a source file 
changes...

The delay is getting annoying for developers, and I'm having trouble 
defending
the decision to use cons instead of gnu-make with some kind of 'make 
depend'...

Any suggestions on how I could speed things up?   Does anyone know if 
scons
handles this kind of situation any better?

Thanks!

Warren




_______________________________________________
[email protected]
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/