SBU calculations

Matthew Burgess matthew at linuxfromscratch.org
Thu Jun 16 12:32:56 PDT 2005


Bruce Dubbs wrote:
> Matthew Burgess wrote:
> 
>>Randy McMurchy wrote:
>>
>>
>>>I don't think the last two binutils
>>>commands belong in the timing of the SBU, as these two commands
>>>aren't involved in the build process of the *binutils* pass1
>>>chapter 5 package. These two commands are used as part of the
>>>setup for binutils in pass2. To me I see this different than
>>>you.
>>
>>
>>Well, I'm in violent agreement with you here, Randy.  Like you though,
>>I'm not sure it much matters whether the two extra instructions are
>>included or not.  I'd prefer they are left out, but I'll defer to
>>whatever the lists' consensus is on this one.
> 
> 
> Just for reference, this is the script I use for my timing build of
> binutils.
> 
> Doing some checking, the timing of:
> 
> make -C ld clean
> make -C ld LIB_PATH=/tools/lib
> 
> takes 5.1% of the total build time.  Changing the process to not include
> this 5% will increase all the others by this amount.  The largest value,
> glibc in Chapter 6, will increase from 12.3 SBU to 12.9 SBU.
> 
> The way it is measured will, of course, affect BLFS, but since we have
> to rebuild everything and remeasure everything for a released based on a
> new LFS anyway, it wouldn't make any difference.
> 
> My only concern is telling users how to measure.  I have always thought
> of the SBU measurements as the time it takes to accomplish the
> procedures in a section of the book, not necessarily the time to build
> the 'package'.   If you are not going to measure all the instructions in
> Chapter 5's binutils, then this needs to be made very clear in the book.

Well, personally I measure them using the following simple rule:

1. Start timing immediately after the tarball has been unpacked.
2. Don't time the running of any testsuite commands.
3. Stop timing immediately after 'make install' has completed.

This applies for all packages, including pass 1 of binutils in chapter 
5.  Configuration time is usually negligible, and isn't overly common in 
LFS, I believe.  So, in the interests of treating all packages the same, 
I think the above is the fairest method of measurement.

If everyone agrees, then minor edits to chapter04/aboutsbus.xml should 
help clarify this.

Cheers,

Matt.



More information about the lfs-dev mailing list