Re: address@hidden: libjava build times]

[Ralf Wildenhues]

Hi Albert,

* Albert Chin wrote on Thu, May 05, 2005 at 09:20:50PM CEST:
> On Thu, May 05, 2005 at 03:17:26PM +0200, Ralf Wildenhues wrote:
> > That one still needs testing, but the idea is to kill all quadratic
> > loops in the func_mode_link initialization:
> > 
> > Stuff like
> >   compile_command="$compile_command $qarg"
> > is better written as
> >   $ECHO " $qarg" >&FD_COMPILE_COMMAND
*snip*
> >   compile_command=`$SED 's/^ //' <"$compile_command_file" | $NL2SP`
> 
> Can you explain how the latter is faster? From inspection, I'd believe
> the first to be faster.

The former scales quadratically with some shells (all I tested on
GNU/Linux), presumably because they do repeated reallocs.  The quadratic
behavior is actually visible when you have on the order of 3000
iterations, as is the case with libjava.  It was not visible with 500
objects yet (my previous test case).  Also, the latter is only a
constant amount (2) of extra processes iff $ECHO is builtin.

The quadratic behavior was by the way very much visible with the object
renaming algorithm -- fnmatch is slow.  I think fixing the libtool part
of piecewise linking is also feasible.

Strictly speaking, we have to decide about `--dry-run' for implementing
this: should we go the way of skipping all these algorithms then because
they create temp files (I think not, output would be mostly unusable),
should we create the temp files outside the build dir (I would rather
not), for example ${TMPDIR-/tmp}, or should we adjust the meaning of dry
run a little: do not modify any output files?

I'm undecided, because one will break the nice feature that you can use
dry run and be sure your build dir will look the same afterwards.  Maybe
use a different build subdir, like `.libtool'?

Sorry to the other developers, by the way, a hardware failure has
kept me from looking at any of the other patches (and doing 1.5.18).

Regards,
Ralf