Re: Performance issues with Cons

[david . weidenkopf]

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

address@hidden Sent by: address@hidden 10/02/2002 08:45 AM

To:        address@hidden         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




_______________________________________________
address@hidden
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/