Re: address@hidden: libjava build times]

[Ralf Wildenhues]

Hi Bob, others,

* Bob Friesenhahn wrote on Thu, May 05, 2005 at 02:05:04AM CEST:
> On Wed, 4 May 2005, Ralf Wildenhues wrote:
> >
> >Sorry for that.  Compilation needs something like libtool-cache, if it
> >is a bottleneck.  BTW, choosing the right shell may also help a lot.
> >Adapting Libtool to do this better for cases of interest might be a
> >cheap way to get more speed quickly.
> >
> >>for all decent platforms, not win32), for the case of many objects.
> 
> I think that the problem is that ltmain.c in the libtool directory 
> only contains:
*snip*
> If someone should care to finish this program, then libtool.m4 can 
> focus on creating the configuration file it needs.

I'd be happy to review your patches, time permitting.

> Libtool has been around since 1996 but its implementation is still 
> fundamentally broken.

Which part is _fundamentally_ broken?  Being a shell script it can be
slow, yes, and quoting is a pain, but you get that with `make',
`autoconf' or `automake' as well, in slightly different settings.

> We try to solve the problem by increasing the 
> amount of problem code (Microsoft approach).

Where did we do that?  You did not mean the roughly 50 lines I added for
a 60% percent reduction in link time, right?  Please show where we
generate problem code.

> Rather than chasing our 
> tails trying to make a moby shell script run faster, maybe we should 
> be thinking about creating a real program that runs quickly.

I get your repeated point about ltmain.c.  But let me tell you
something about programming efficiency: if we can manage to put
something like libtool-cache (but not broken) into libtool, let's
say in roughly 30 hours work including testing, then I think that is
reasonable.  If you tell us that you can spend 300 hours
implementing ltmain.c within the next few months, then I'll be happy
that you found a sponsor and the time for doing this work.  _And_
I'd still be amazed at your programming and testing speed.

Note I am not trying to say this is futile, or a waste of time
(actually I'm unsure about the latter).  But I do know that
incremental improvement of the current code base has so far been
much more time efficient than a rewrite would be.  Also I do believe
that a continuation of this _can_ lead to libtool execution time to
be negligible compared to compilation time, within a timeframe I can
afford to spend on Libtool beside my thesis and job.

Please also note that GCC has such kind of sponsoring (in different
forms) necessary for such work.

IOW: don't talk, start sending patches, just like I did when I saw
which parts of Libtool needed work.  And to undermine that, I will
send another mail to this thread containing a first speedup patch.

Regards,
Ralf