libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: func_arith and func_len


From: Ralf Wildenhues
Subject: Re: func_arith and func_len
Date: Sun, 20 Apr 2008 03:26:56 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

* Roland Mainz wrote on Sun, Apr 20, 2008 at 03:03:24AM CEST:
> On 4/20/08, Ralf Wildenhues <address@hidden> wrote:
> > Second, if you can prove to me (by posting
> >  timing comparisons) that conversion from integer to string or vice
> >  versa,
> 
> Here come the requested numbers:
> -- snip --
> $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i < 100000 ; i++ )) ;
> do (( sum=sum+1 )) ; done ; print $sum'
> 100000

Libtool does at most C + 2 * O additions, with O being the number of
objects, and C a small constant, 5 or so.  And that's only in link mode.
So, ...

> real          3.89

> $ timex ksh93 -c 'integer i sum=0 ; for (( i=0 ; i < 100000 ; i++ )) ;
> do (( sum=$sum+1 )) ; done ; print $sum'
> 100000
> 
> real         18.70

we're talking about 0.5 seconds for the largest link I've ever seen,
comprising 3000 objects.  I'm honest I'm surprised it should be that
much, but I don't think it will be noticeable compared with the run
time of ld and ar.  FWIW, on my laptop the above loops take 0.3 and
0.6 seconds, respectively (ksh93 on GNU/Linux).

> > has *any* performance impact whatsoever on Libtool, I'll gladly
> > send lots of beer your way.
> 
> Erm... I don't have a good way to benchmark libtool... all machines I
> have access to are either heavily overtaxed with swapping or shared
> between multiple users (an option may be to use the "realtime
> scheduler class" on Solaris for benchmarking but that requires "root"
> access... ;-/ ).

If you're serious about this, getting a shell account to do benchmarking
is not a problem.  Besides, looking at process time is useful even if
it's not correlated well with real time.

> BTW: below is the Solaris patch for libtool 1.5.x I've used to improve
> the performace:

Thanks for the patch.

> Chunk one makes sure we use "print -r" for ksh-based shells because
> otherwise the automake stuff will attempt to use /usr/ucb/echo (which
> requires a |fork()|+|exec()|)

Ah, prefering 'print -r' over /usr/ucb/echo is a good idea.  Will look
into a patch to do this properly.

> ; the 2nd chunk enables lots of builtins
> present in ksh93 version 's+'  (which saves lots of fork()|+|exec()|
> calls, too) ...

You might have posted before, but can you please show again how much
just the builtin stuff saves you in practice?  It would be most
interesting to see numbers comparing the current development tree
against the current development tree with your patch added (but with
'print -r' used in both cases).  1.5.x is not a good comparison, we're
not developing that any more.

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]