Re: Performance issues with 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
> dependencies somewhere, and only rebuild them when a source file changes...

But you still have to examine each include file to see if it's changed, 
all the way down the tree.  You can avoid checksumming it if the date 
hasn't changed, but even that can be problematic in an NFS environment.

Cons can avoid re-checksumming the file if the timestamp matches; see 
"Using build signatures to decide when to rebuild files" in the cons 
docs.  Try using
    SourceSignature '*' => 'stored-content';
and see if that helps.  (Requires a recent cons version.) From the cons 
docs:

This specifies that Cons will use pre-computed content signatures
from F<.consign> files, when available, rather than re-calculating a
signature from the the source file's contents each time Cons is run.  In
practice, this is safe for most build situations, and only a problem
when source files are changed automatically (by scripts, for example).
The Cons default, however, errs on the side of guaranteeing a correct
build in all situations.

You are using one of the native-code MD5 implementations, right?  The 
perl-based one is dog-slow.

-- 
. . . . . . . . . . . . . . . . . . . . . . . . .
Gary Oberbrunner                [email protected]
GenArts, Inc.                   Tel: 617-492-2888
8 Clinton Street                Fax: 617-492-2852
Cambridge, MA 02139 USA         http://web.genarts.com




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