Re: libtool performance status

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Mon, Apr 21, 2008 at 05:14:00PM CEST:
> On Mon, 21 Apr 2008, Ralf Wildenhues wrote:
>>
>> If they were lower in between, and since increased, there must have been
>> at least one regression along the way.  Can you use git bisect to
>> identify one?
>
> Remember that you fixed an expr-related bug which was impacting FreeBSD 
> and causing an error message to be displayed rather than code being 
> executed.  Perhaps this fix adds a small cost?

Unlikely.  It removes a fork&exec and adds a pattern match and ${foo#bar}
substitution.  Both of the latter should be pretty quick compared with
the former.

To put some sort of proof to my claims, here's what I get building GM
unoptimized (CFLAGS=-g) on GNU/Linux with Libtool 2.2.2. and current
master (all timings best of three):

2.2.2:
110.31user 30.73system 2:21.01elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+5714405minor)pagefaults 0swaps

master:
107.42user 28.04system 2:16.51elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+5069147minor)pagefaults 0swaps

Looks like a small but definite improvement to me.  :-)

Also note that there is only 1.05s of unaccounted-for elapsed time, also
the lower page fault count is a pretty good indicator that things have
not gotten worse.

To break things down further, I recorded (with make -n) most libtool
calls, split them into --mode=compile and --mode=link, put them in a
shell script, and added '-n --silent' so we only measure libtool script
overhead.

compile mode 2.2.2:
5.72user 2.30system 0:07.93elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+537316minor)pagefaults 0swaps

compile mode master:
4.95user 1.21system 0:06.14elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+292254minor)pagefaults 0swaps


link mode 2.2.2:
12.11user 7.92system 0:19.74elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1662149minor)pagefaults 0swaps

link mode master:
11.91user 7.10system 0:18.94elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1450595minor)pagefaults 0swaps

Again not much, but consistently better (and much better than 1.5.x).

> Since only 54% of the time is attributed to user+system time the rest of 
> the time must be spent doing things like moving the disk drive heads, 
> waiting for I/O, servicing interrupts, or running other programs (none in 
> this case).

Hmm.  That may or may not be libtool's fault, though; linking in itself
isn't so cheap, I/O-wise.

Can you please check whether
  libtool --tag=CXX --config

is identical for each of the builds you timed?

Thanks
Ralf