John Reiser wrote: > The benchmark code and measurements [snipped] are not a good comparison > with the actual environment of low-memory mode. In particular, the use of > swap space is likely in low memory mode, but almost certainly not present > in the measurements reported above. Any actual use of swap space (or paging) > will tend to increase the delay, and increase the relative advantage > of avoiding fruitless searching. Partman runs before swap is available. Also, the kernel is unlikely to ever swap out its filesystem cache and syscall handlers. > It takes a minute or so to change partman by adding something such as > "export PATH=/bin". If the searching in partman becomes faster by >= 0.2 > second per run, and if partman is run some thousands of times in the future > life of the installer, then that is a net savings, and not a waste. Perhaps > the intended claim was, "I'd rather spend my time doing something with a > larger payoff." So would the humans who use partman. No, my point is that it's pointless to nibble away at optimising something in 1% increments. Instead find the actual large timesinks, and optimise those. Also, work with real-world numbers, not guesses. (BTW, I forgot to CC you, but AFAICS your numbers in #492077 are off by several orders of magnitude.) > Consider this shell code: > which runs in 22.2 seconds on my NSLU2 for 1000 executions of "cat /dev/null" > in an environment much more similar to real partman than previous benchmarks. > Changing to "PATH=/bin " runs in 21.5 seconds, which is 0.7 seconds faster. > Altering the search path does achieve measured savings. Actually, the result is similar to that of my C-based tests. I measured an added 0.000014 seconds per cat invocation due to PATH; on the same hardware with your test I get a value of 0.000020. > The original bug report contains two further paragraphs which give specific ways > to avoid fork+exec: > Second, use a shell builtin if possible. [ $(< file) ] > Third, use shell text strings where possible. > [ PM':'$dir':'default_response=$( ... ) ] > "$(< file)" turns out not to work on various shells other than bash. > The use of non-literal variables was panned by Frans Pop as being too obscure, > although there are projects which use them. [Look at libtool to see some > mind-boggling obscurity in shell programming.] > > However, there is another shell builtin which does input without fork+exec, > namely 'read'. If the replies are restricted to be only one line, then: > read < $dir/default_response > default_response="$REPLY" > achieves the same effect as > default_response=$(cat $dir/default_response) > but without requiring fork+exec. So 'read' looks like a promising replacement. Or one could teach busybox shell to jump to the in-busybox implementations of cat and all other busybox commands, thereby eliminating every exec in partman except for those needed to run subshells. (It'd still have to fork, but linux can fork very fast, and most shell tricks above involve a fork due to the use of subshells.) -- see shy jo
Attachment:
signature.asc
Description: Digital signature