Possible evidence of performance regression for 8.1-S (vs. 7.1)

[Dan Nelson]

In the last episode (Oct 20), David Wolfskill said:
> Almost 2 years ago, we migrated from a lightly-patched 6.2-R to 7.1-R with
> 5 commits that were made to 7.1-S backported to it.  On the same hardware
> (not the HP mentioned above), I measured a 35% reduction in elapsed time
> for one particular form of the build in question.  This was encouraging.
> 
> A couple of days ago, I updated the active slice on my 8.x reference
> machine to 8.1-STABLE #5 r214029 and proceeded to start some timed builds;
> here are some fairly raw timing data:
> 
>      Start        Stop      real      user       sys  OS
> 1287436357  1287461948  25590.99  81502.22  18115.07  8.1-S
> 1287462797  1287488766  25969.26  81452.14  17920.14  8.1-S
> 1287489641  1287515287  25645.84  81548.40  18256.52  8.1-S
> 1287516151  1287541481  25329.64  81546.23  18294.10  8.1-S
> 1287542355  1287568599  26244.59  81431.47  17902.39  8.1-S
> 
> 1287525363  1287546846  21483.13  82628.20  21703.09  7.1-R+
> 1287548005  1287569100  21094.63  82853.19  22185.02  7.1-R+
> 1287570300  1287591371  21071.33  82756.81  21943.22  7.1-R+

An observation:  on 8.1, both user and sys times are less, but real time is
higher.  So 8.1 finished the build using less CPU, but spent more time
waiting for something else.  Disk?  Network?  I don't suppose the machines
are low enough on RAM that you end up swapping at any point?  Maybe there
was a change to /usr/bin/make that is causing it to launch jobs slower? 
Julian's suggestion of booting the 8.1 kernel on the 7.1 OS will definitely
narrow down the list of suspects.

-- 
	Dan Nelson
	dnelson at allantgroup.com