Re: "libtool" performance...
Ralf Wildenhues wrote:
> * Roland Mainz wrote on Fri, Apr 11, 2008 at 04:59:15PM CEST:
> > Ok... but "dolt" may been to be adopted to other compilers (like Sun
> > Workshop/Forte/Studio, icc etc.) and then it will be a bit more than the
> > 10 lines (and adopting it for other POSIX-like shells may be nice, too -
>
> Josh measured against Libtool 1.5.x. Libtool 2.2.2 has a lot less
> overhead in compile mode than 1.5.x, see the numbers Ross posted, and
> the list archive of libtool-patches for several improvements including
> numbers; and we are currently working on improving things a bit more,
> targeting improvements that help all shells which support XSI
> extensions (and falling back to the slow code for other shells).
What do you mean by "XSI extensions" ?
BTW: One thing which could be improved in both "libtool" and "dolt"
(beyond the stuff listed in
http://www.opensolaris.org/os/project/shell/shellstyle/) would be to get
rid of the "echo" h*ll - almost every version of Unix/Linux and shell
has it's own version of "echo" (Solaris even has multiple one:
/usr/bin/echo, /usr/ucb/echo, /usr/gnu/echo and the { bash, Bourne, csh,
ksh88, ksh93, zsh } builtin version of "echo" - all of them with
slightly different behaviour).
A more portable solution would be to use the "printf" command (which is
usually a shell builtin (at lest in bash+ksh93's case)) which is part of
the POSIX standard (the POSIX people were aware of the "echo" h*ll since
a long time and choose to create a new utilty than trying to fight each
and every OS+shell vendor/author... :-) ) and therefore has guranteed
behaviour for quoting, backslashes etc. (and avoids undesired
sideeffects when a variable contains backslashes, e.g. $ foo="\a
chicken" ; echo "$foo" # will result in some OS/shell-specific string
while $ foo="\a chicken" ; printf "%s\n" "$foo" # will precisely print
"\achicken").
> While the multi-thousand line script can't get as fast as dolt -- after
> all, dolt isn't portable to non-bash,
Well, I can provide patches to make it at least compatible to all POSIX
compatible shells (AFAIK that would only require minor adjustments...).
> also there's functionality that
> libtool compile mode offers that dolt doesn't -- we expect compile mode
> to become fast enough that the overhead shouldn't be a big problem for
> practical use, and we expect that to come without the need for users to
> change their configure.ac scripts at all.
>
> Meanwhile, updating to 2.2.2 would be a good idea, its link mode has
> also become considerably faster than 1.5.x at least for some use cases.
> We would appreciate bug reports for particular remaining performance
> bottlenecks.
Question for both "dolt" and "libtool" developers:
Where should I send bug reports/patches to ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: "libtool" performance...
[ since my mails are being dropped for the other lists anyway, I might
as well drop the xorg and gnome-devtools lists ]
* Roland Mainz wrote on Mon, Apr 14, 2008 at 03:26:11PM CEST:
> Ralf Wildenhues wrote:
> > [...] we are currently working on improving things a bit more,
> > targeting improvements that help all shells which support XSI
> > extensions (and falling back to the slow code for other shells).
>
> What do you mean by "XSI extensions" ?
Shells that support Posix and XSI extensions to Posix. Stuff like
${variable%%pattern}
${variable#pattern}
Hmm, they are required by Posix even; I wonder whether they used to be
extensions required by XSI only, or why else we would have chosen that
name. Anyway, that's what I mean.
> BTW: One thing which could be improved in both "libtool" and "dolt"
> (beyond the stuff listed in
> http://www.opensolaris.org/os/project/shell/shellstyle/) would be to get
> rid of the "echo" h*ll - almost every version of Unix/Linux and shell
> has it's own version of "echo"
I'm not sure what you're talking about: the configure part of Libtool
looks whether 'echo' doesn't interpret backslashes, and otherwise
searches for a (preferably builtin) command that prints without
expanding. And of course we also try printf, but it's known to be buggy
on some systems. It sets $ECHO to the preferred choice.
If you're experiencing a quoting bug, or a system where we choose a
non-builtin for $ECHO where a builtin would do the job just as well,
then please report a bug.
Also, some of the recommendations in the link you quote are rather
questionable. For example, the code in
is much more portably (and likely faster, too) replaced by
case $x in *foo*) do_something;; esac
at the expense of using BREs over EREs, of course.
Also, some items explicitly recommend to use nonportable constructs over
portable ones, even without efficiency concerns. This is not a way to
go for Libtool.
> Question for both "dolt" and "libtool" developers:
> Where should I send bug reports/patches to ?
Libtool patches go to [EMAIL PROTECTED] Note that nontrivial
patches require copyright assignment to the FSF.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: don't let libtool infer the tag
* Mike Frysinger wrote on Mon, Apr 14, 2008 at 01:41:32AM CEST: > On Sunday 13 April 2008, Ralf Wildenhues wrote: > > So don't do this, please. Supply --tag=CC if your compiler name doesn't > > match. > > i doubt people will care at this point, but ive done a bit of work in Gentoo > to make the tag inferring "better". ive done this as there are still a few > packages out there that insist on using libtool found in $PATH. we've been > killing them off over time, but we still havent gotten them all, so this > painful patch lives on. > http://sources.gentoo.org/sys-devel/libtool/files/1.5.6/libtool-1.5-filter-host-tags.patch Well, this patch is really ugly. Not only is it a further cause of overhead, it also can induce using libtool with a compiler or host system for which it hasn't been configured. Which can cause all kinds of interesting failures. So really please supply --tag to fix these. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: don't let libtool infer the tag
On Monday 14 April 2008, Ralf Wildenhues wrote: > * Mike Frysinger wrote on Mon, Apr 14, 2008 at 01:41:32AM CEST: > > On Sunday 13 April 2008, Ralf Wildenhues wrote: > > > So don't do this, please. Supply --tag=CC if your compiler name > > > doesn't match. > > > > i doubt people will care at this point, but ive done a bit of work in > > Gentoo to make the tag inferring "better". ive done this as there are > > still a few packages out there that insist on using libtool found in > > $PATH. we've been killing them off over time, but we still havent gotten > > them all, so this painful patch lives on. > > http://sources.gentoo.org/sys-devel/libtool/files/1.5.6/libtool-1.5-filte > >r-host-tags.patch > > Well, this patch is really ugly. Not only is it a further cause of > overhead, it also can induce using libtool with a compiler or host > system for which it hasn't been configured. Which can cause all > kinds of interesting failures. So really please supply --tag to fix > these. the tag inferring is all ugly. i'm not suggesting this patch cleans it up or anything, just that it makes it a little less painful if you dont plan on fixing the package to do things right. i agree completely that explicitly specifying the --tag is the right solution. i dont think the additional overhead to the tag inferring is a real issue -- if you're inferring tags, you're already doing it wrong ;). -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool performance and shells
Since it has been claimed that libtool causes a lot of build overhead, I have been doing a *lot* of testing here with latest development libtool. We already know that libtool 1.5.X is very slow so it is not worth worrying about that and it is more worthwhile to get projects migrated to libtool 2.2.X since it is much faster. Peter O'Gorman came up with a simple useless code parsing benchmark which showed that GNU bash could be the Worlds Slowest Shell (TM) except for a Korn shell clone called 'pdksh' which never completed at all. Other tests also pointed out that bash seemed to be a bit sluggish. DTrace shows that bash spends an awful lot of time in memset() as compared with the other shells. Simple shell benchmarks seemed to indicate that shells derived from the Almquist shell (http://en.wikipedia.org/wiki/Almquist_Shell) were the fastest and smallest. Ksh93 was almost as quick. Bash was slowest at simple contrived benchmarks. However, there is an old saying "The proof is in the pudding". I have run overall timings of configure and full builds using various shells on different systems and found that on average, bash was not significantly slower at running the configure script. I also found that bash was not significantly slower for an overall libtool-based build. Bash is never the fastest, but when it is slower there is not a significant impact to overall build time. There are some systems where there is some benefit to using a shell other than bash, but the difference does not seem large enough for Autoconf and libtool to be concerned enough to use a different shell selection algorithm. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: "libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half
Attila Kinali wrote: > If you care about sane tools, why do you use auto* and libtool > in the first place? Because converting X.Org's approximately 300 packages to anything else would be even more painful? (And believe me, I curse libtool regularly, and have had to find more ways to undo it's damage than I can count, so I'm not a fan either.) It's going to have to be a whole lot better than auto* and libtool to be worth the effort to move all of those, and it's going to need people in X.Org who know the new tools, while we've all learned the ones we have already. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ http://lists.gnu.org/mailman/listinfo/libtool
