Performance testing (pass 1)

[Craig Ringer]

>>>Timings are average of 5 launches. [...]
> 
> I suppose if you're evaluating a system like WinDOwS or MacOS<X,
> then boot time and launch time ARE the most signifigant times to evaluate.
> On a UNIX based system (CRAM the trademark, it's a generic term)
> you boot once, launch once, and just use it day after day after day
> after day...

This isn't always true. Many people /prefer/ to shut machines down when 
not using them for long periods, for a variety of reasons. Noise can be 
a big one; power consumption is also significant. Some people also need 
to dual boot to use the machine for everything they want to be able to 
do - in this case, boot times are /very/ significant.

That said, it's only one bit of the whole performance area, and for many 
a totally insignificant one. For example, I don't care if the dual xeon 
at work takes 10 minutes to boot (well... unless I've had to do an 
emergency outage during production time - *uggh*) but I care if my 
desktop takes long at all.

IMHO, it'll be much easier to make the "who cares how long it takes to 
boot" argument once swsusp is reliable and quirk-free on most hardware 
and ACPI support is working well (so you can drop to S3 with no fuss). 
With the current state of power management under linux, it's often just 
not practical to leave machines on all the time.

So... put me down as someone who cares very much indeed about boot 
times. I'm lucky that swsusp works well on my laptop, but my desktop 
appears to be a no-hoper for any kind of decent PM under Linux at the 
moment. Sure, I don't think they're critical, and there are lots of 
things that are vastly more important - but I do care how long the 
system takes to be useable.

For this reason, I'm quite interested in the possibility, in future, of 
integrating a parellised rcS/run-parts to allow the execution of 
multiple non-interdependent boot processes at the same time. This would 
be especially handy when one is waiting on disk I/O while another is 
thrashing the CPU, etc.

Craig Ringer