On 26/05/10 12:03, drago01 wrote:
On Wed, May 26, 2010 at 12:53 PM, James Findley<sixy(a)gmx.com>
wrote:
> [...]
> Sorry. I like fast boots as much as the next person - this is just a
> bad trade. We only save ourselves (much) less than a second of boot
> time, but turn a common and simple practice into a major headache.
>
> If anyone has a bash/awk/whatever initscript that actually takes a
> user-noticeable amount of time to run, this means that you've done
> something badly wrong - it isn't the language at fault. I would be
> happy to help you fix this - just poke me on IRC.
But the speed ups _add_ up ... lets say you save x, y, z time uints
for script A, B and C ...
you end up saving x+y+z.
Oh, I agree that they add up completely. It's just that they don't add
up to very much. 0.3 seconds for 93 spawns of awk, remember?
In terms of a helpful comparison let's assume you run 50 initscripts on
boot (unlikely on a desktop - but lets go for worst case)
We will compare 3 things, and run each comparison 3 times to get a mean
result.
1) a poorly written bash script, that does horrible things like piping
grep to awk (sidenote: this is always wrong, don't do it), spawning
subshells, sourcing stuff when not required, etc
2) a clean bash script, that still calls awk but gets rid of unnecessary
sources, subshells, etc.
3) an incredibly lightweight C program that just execv()'s the program
in all cases the program we will use is /bin/true - we just want
something consistant and small. Each is run 50 times in a loop.
Result:
1: 0.57 seconds
2: 0.20 seconds
3: 0.15 seconds
cleaning up the initscripts - which are often fairly poorly written -
saves us nearly as much as writing them in C. And even the worst case
is only ~ half a second total across the entire boot process.
I just don't see any evidence at all that writing out initscripts in C
really gets us anywhere useful in the real world, and I am extremely
sure that it would be a significant pain in the ass to many, many people.
Yu want the initscripts to run faster? Sure. lets clean them up. For a
start /etc/init.d/functions is a mess that takes way to many CPU cycles
for what it does - and includes a lot of functions that really aren't
widely used enough to justify sourcing by _every_ initscript.
Massively obfuscating our boot process, however, is not the answer.
-siXy