[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: libjava build times]
From: |
Ralf Wildenhues |
Subject: |
Re: address@hidden: libjava build times] |
Date: |
Thu, 5 May 2005 11:58:42 +0200 |
User-agent: |
Mutt/1.5.9i |
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
Re: address@hidden: libjava build times], Peter O'Gorman, 2005/05/04