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 31.xxx to 36.xxx 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 2.6.35.5, the later builds were on 2.6.36-rc6. So, I went back to 2.6.35.5, 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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
