This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
[Christian Goetze <cg@resolute.com>] First benchmarks for non-recursive build...
- To: libc-hacker@cygnus.com
- Subject: [Christian Goetze <cg@resolute.com>] First benchmarks for non-recursive build...
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 10 Dec 1998 13:34:51 -0800
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
Might be interesting to keep in mind for the makefile rewrite.
I, for example, recompile on specific directories when I change
something. A rewrite would have to allow this as well.
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
- To: cook-users@canb.auug.org.au
- Subject: First benchmarks for non-recursive build...
- From: Christian Goetze <cg@resolute.com>
- Date: Thu, 10 Dec 1998 12:55:15 -0800 (PST)
- cc: Dennis Blay <blayde@resolute.com>
I'm in the process of redesigning my current recursive build system to a
non-recursive one similar to the one recommended in the cook user's guide.
I have finished the manifest generation and the header dependency parts.
On a sparc 2 dual processor machine with 256MB of memory and a disc array,
operating on a project with approc. 7,800 source files, it takes about 90
seconds for the system to realize that everything is up to date.
This is of course a lot faster than my recursive build system would take
for a whole system build, but it is a lot slower than a typical
developer-invocation of my old recursive system, which is about 1-2
seconds inside the average directory.
In practise, I fear that even though the actual build times might average
out favorably for the non-recursive system, the _impression_ will be of a
very slow system, since every invocation will at least take 90 seconds.
I'm not sure if there is a good solution to this except a lot of
education... I'm still not sure if some segmentation wouldn't make sense,
maybe not at the library level but perhaps at a subsystem level...
For now, I will continue down this route and see how the actual compiling
and linking will fare - I fear it will add another 10-15 seconds to the
basic overhead...
One nice thing is that using c_incl instead of a perl script is a huge
gain, in particular in combination with the cascade recipes...
Has anyone already patched c_incl to support java's import lines? Even
though the javac is a whole build system in itself, it is still necessary
to know that you need to invoke it _somewhere_ in the first place...
--
cg
To unsubscribe from this list: send the line "unsubscribe cook-users" in
the body of a message to majordomo@canb.auug.org.au