Bug#492086: partman: menus are very slow

[John Reiser <jreiser@BitWagon.com>]

Joey Hess wrote:

> Conclusion 2: Benchmark before optimising. In this case, trying to
> optimise away the wrong system calls is a waste of time.

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.

> PS: Reordering PATH to put /usr/bin first and omit /usr/local/bin would
>     be the easy way to optimise this, IF searching the path were actually
>     a significant time sink. However, it does not appear to be.

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.

Consider this shell code:
-----
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binPATH=/bin \
busybox sh -c '
  for i in 0 1 2 3 4 5 6 7 8 9
  do
    for j in 0 1 2 3 4 5 6 7 8 9
    do
      for k in 0 1 2 3 4 5 6 7 8 9
      do
        cat /dev/null
      done
    done
  done
'
----
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.

> PPS: Actually _eliminating_ calls to cat and other binaries in partman would
>      of course help. A partman written in C should be 100 to 1000 times as
>      fast as the current one.

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.

--