Re: automake 1.8 performance problems

[Alexandre Duret-Lutz <adl at src dot lip6 dot fr>]

>>> "Harlan" == Harlan Stenn <hstenn@cisco.com> writes:

[...]

 >> Also it would be interesting to describe your tree a bit
 >> more (I presume you cannot publish nor reduce your test
 >> case...).  How many configure.{in,ac} do you have?

 Harlan> One in the main tree, and I do some Horrible Things to
 Harlan> effectively invoke "autoreconf" in, say, 4 other
 Harlan> subtrees (grub, ntp, etc.).

Damn.  I was hopping the answer would be >100 :(

 >> Do you use lots of AM_CONDITIONALS? (How many per-subproject, and how many
 >> per-Makefile.am?)

 Harlan> More that I would like - at the moment there are 41.
 Harlan> Most Makefile.am's use between none and maybe 8.

In fact 1.8 ought to be able to deal with lots of conditionals
better than previous versions.  Because some "explosive"
algorithms have been removed.


Another question, is whether you use lots of sources in
subdirectories or sources with per-targets flags.  These implies
separate compile rules for each files, hence big Makefiles,
hence slow generation of Makefiles.  If that is the case, it
could help to try CVS Automake.

 >> You could also run automake in `--verbose' mode and try to get
 >> the feeling of were time is spent.

 Harlan> We do, and I haven't noticed anything obvious; I'll
 Harlan> look again.

There have been several changes between 1.6 and 1.8 to abstract
some of the most internal structure of Automake (how locations,
conditions, variables, and rules are handled).  These
abstractions have a price (more indirections), and this is
likely to be responsible for part of the slowdown you see, but 
  1) I don't know how to evaluate it
  2) the slowdown looks too important to be caused just by this

I wish we could profile Automake, say over its test suite.
Does anybody knows how we could do this?
-- 
Alexandre Duret-Lutz