On 26/05/10 12:03, drago01 wrote: > On Wed, May 26, 2010 at 12:53 PM, James Findley<sixy@xxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
