Variability in build times.

Ken Moffat ken at
Mon Oct 18 14:19:58 PDT 2010

 I've never imagined that build times were exactly repeatable, but
I'd assumed that, *on an unloaded system with only a browser
running* the times would be fairly close, say plus or minus 3%.
Now, I start to wonder.

 I'm reviewing the options for abiword, and my build times are all
*considerably* longer than the time from when I first built and
installed the packages.  And the build/install sizes were initially
much bigger.  The abiword configure script has many old optional
dependencies which either no longer apply (skipped, for some
reason), or don't apply on linux (primarily, things for plugins)
which don't appear in the output from configure, but are
nevertheless still listed as dependencies by some distros (Hello,
fedora).  Originally, my bigger and longer builds made me suspect
that one of the (few) things I build after abiword was in fact an
optional dependency, but after looking at the build logs
line-by-line (twice - first time was on a system from before I
installed boost, in case that was the problem, and I thought I was
seeing extra whitespace from the change from make-3.81 to 3.82 - in
fact it was the second item below.   So far I've only found two
variations -

1. My own builds use --disable-static.  Abiword now provides
libabiword, and on x86_64 allowing it to build a static lib as well
as a shared one effectively doubles the time (probably something to
do with choice of pic / non pic, on i686 it probably doesn't matter).

2. My own builds pass CFLAGS and CXXFLAGS of '-O2' which is
reasonably normal.  Abiword defaults to *not* building a debug
version, but nevertheless manages to pass '-g -O2'  to library
functions, instead of the '-O2 it uses elsewhere.  This slightly
increases the build time and significantly increases the size, both
for the build and for the installed files.  After setting these flags
in current builds I've still got a *slightly* bigger build than what
my buildscripts claimed, but I've long suspected there is a bug in
the space calculation of my buildscripts, as it has several times
been a little less than what manually building a package produces.

BUT ... I'm still 13% slower than the original build.  Looking at
just the times for 'configure', on this box I'm seeing a range from to seconds, without any obvious correlation to the
option(s) passed as switches.

 After that, I wondered if it was a kernel regression - the first
build was on, the later builds were on 2.6.36-rc6.  So, I
went back to, but the build time was about 3% slower than
the previous 2.6.36-rc build (which was itself 13% slower than the
similar original build).  3% doesn't worry me.  13% to 16% makes me
wonder how repeatable ANY of these figures are.

 Has anybody run a series of builds on any package (on the same
system, with the same options) to see how much variation occurs in
the elapsed time ?

 Maybe I should just stop worrying and record my actual SBUs when I
upgrade a package, whilst recognizing that they have a range of *at
least* plus or minus 10% [ i.e. in this case, as on previous initial
builds (pre/post make-3.82) on my other box, I got lucky with a fast
build ].  If that's true, I'm worried that I won't remember if I
expect this to be a fast or a slow build, and I'll have to ask
myself "Do I feel lucky?" ;-) [ with apologies to Mr Eastwood ]

 Any thoughts, or alternative suggestions ?

Confused, of Brighton
das eine Mal als Tragödie, das andere Mal als Farce

More information about the blfs-dev mailing list