Josh Triplett josh at freedesktop.org writes:
Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
mode. Dolt runs any necessary system-specific or
configuration-specific logic as part of configure, writes out a simple
shell script doltcompile[1], and substitutes it for libtool
* Tor Lillqvist wrote on Thu, Apr 10, 2008 at 09:54:35AM CEST:
It speeds up builds on Win32 very
nicely. http://libtool-cache.sourceforge.net/
I don't remember well; was libtool-cache more than marginally beneficial
on non-w32 systems as well?
Maybe some libtool-cache-like functionality could
* Bob Friesenhahn wrote on Thu, Apr 10, 2008 at 07:51:57AM CEST:
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
This is a list off shell functions that appear in the generated libtool
script on my linux system (one of Ralf's patches is applied). Yes, we
could probably move these around some to get
Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Thu, Apr 10, 2008 at 07:51:57AM CEST:
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
This is a list off shell functions that appear in the generated libtool
script on my linux system (one of Ralf's patches is applied). Yes, we
could probably move
Let me just point out another, old but apparently not well known, more
portable imrovement on libtool, libtool-cache. libtool-cache doesn't
replace libtool, but as can be guessed from its name, it just avoids
running libtool if the actual shell commands that would be executed by
libtool can be
On 10 Apr 2008, at 02:18, Peter O'Gorman wrote:
Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Thu, Apr 10, 2008 at 07:51:57AM CEST:
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
This is a list off shell functions that appear in the generated
libtool
script on my linux system (one of Ralf's
Hello Josh,
can we limit followups to a subset of this impressive array of mailing
lists? Say, to libtool@gnu.org? That would be readable at
http://thread.gmane.org/gmane.linux.debian.devel.general/126905.
Thanks.
* Josh Triplett wrote on Wed, Apr 09, 2008 at 12:34:18PM CEST:
Libtool knows
Many packages use GNU autotools (automake and autoconf) to build, to
the point that ./configure make represents one of the most common
build procedures for Free Software packages. Libraries using
autotools typically use GNU Libtool, partly because it works on almost
any system and partly because
Josh Triplett [EMAIL PROTECTED] - Wed, 09 Apr 2008 03:34:18 -0700
Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
mode.
Excellent, impressive :)))
___
http://lists.gnu.org/mailman/listinfo/libtool
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
Curious: can you please state which Libtool version you timed against,
and if not 2.2.x, redo timing against 2.2.2? Not that I expect wonders,
but I expect something better than what you measured.
I just tested this out on my laptop with
Ralf Wildenhues wrote:
can we limit followups to a subset of this impressive array of mailing
lists? Say, to libtool@gnu.org? That would be readable at
http://thread.gmane.org/gmane.linux.debian.devel.general/126905.
Thanks.
Sure. I assumed that anyone wanting to respond would do so to the
Josh Triplett wrote:
I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
However, when I looked at 2.2.2, it still seems to have a
multi-thousand-line shell script; do you just expect the benefit to
come from the new shell-specific optimizations?
Hi Josh,
There are
* Josh Triplett wrote on Wed, Apr 09, 2008 at 06:02:36PM CEST:
Ralf Wildenhues wrote:
Curious: can you please state which Libtool version you timed against,
and if not 2.2.x, redo timing against 2.2.2? Not that I expect wonders,
but I expect something better than what you measured.
I
Ralf Wildenhues wrote:
That gave the biggest speedup on
GNU/Linux (where forks are relatively cheap).
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/7230
This entire message just goes to prove that I do not have a good memory.
I had completely forgotten that you sped up compile mode
On Wed, 9 Apr 2008, Ross Burton wrote:
I realise this isn't libtool 2.2, so I'm willing to believe there are further
speedups.
What I notice from your timings is that libtool 2.1 takes much less
system time than libtool 1.5.26-3 but the user time is quite similar.
The real time is surely
On Wednesday 09 April 2008 03:34:18 am Josh Triplett wrote:
Meanwhile, modern systems such as GNU/Linux have reasonable library
mechanisms, and need relatively little of the machinery in libtool.
On these common systems, it would significantly improve build times to
avoid running that libtool
On Wed, 9 Apr 2008, Josh Triplett wrote:
I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
However, when I looked at 2.2.2, it still seems to have a
multi-thousand-line shell script; do you just expect the benefit to
come from the new shell-specific optimizations?
Since
Hi Ross,
* Ross Burton wrote on Wed, Apr 09, 2008 at 03:44:40PM CEST:
EDS with libtool 1.5.26-3
real 4m35.934s
EDS with libtool 2.1 (2.1a+cvs1.2525+20071016-1)
real 4m10.648s
EDS with dolt
real 3m40.974s
OK, so we're already half-way there, and the speedup in Libtool 2.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bob Friesenhahn on 4/9/2008 11:15 AM:
| On Wed, 9 Apr 2008, Josh Triplett wrote:
|
| I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
| However, when I looked at 2.2.2, it still seems to have a
| multi-thousand-line
On Wed, 9 Apr 2008, Eric Blake wrote:
| Since shell scripts are not compiled, the size of a shell script has
| very little to do with its execution time.
On the other hand, recent improvements in autoconf 2.62 proved that we
were able to speed up testsuite performance by more than 10% by merely
Eric Blake wrote:
According to Bob Friesenhahn on 4/9/2008 11:15 AM:
| On Wed, 9 Apr 2008, Josh Triplett wrote:
|
| I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find.
| However, when I looked at 2.2.2, it still seems to have a
| multi-thousand-line shell script; do you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bob Friesenhahn on 4/9/2008 7:01 PM:
| There may be value to extracting these shell functions into separate
| files which are sourced only when needed. This way the overhead of
| parsing linking code is not encountered while compiling,
Bob Friesenhahn wrote:
On Wed, 9 Apr 2008, Eric Blake wrote:
| Since shell scripts are not compiled, the size of a shell script has
| very little to do with its execution time.
On the other hand, recent improvements in autoconf 2.62 proved that we
were able to speed up testsuite performance
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
(using bash)
$ for y in {1..100}; do echo func_notused${y} () { parse.sh; for x
in {1..1}; do echo foo parse.sh; done; echo '}' parse.sh;
done; echo 'echo Done' parse.sh
It seems that the slowest possible shell is selected by default.
Maybe
Bob Friesenhahn wrote:
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
(using bash)
$ for y in {1..100}; do echo func_notused${y} () { parse.sh; for x
in {1..1}; do echo foo parse.sh; done; echo '}' parse.sh;
done; echo 'echo Done' parse.sh
It seems that the slowest possible shell is
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
This is a list off shell functions that appear in the generated libtool
script on my linux system (one of Ralf's patches is applied). Yes, we
could probably move these around some to get func_mode_compile closer to
the top.
The important thing is not
26 matches
Mail list logo
