* 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
