Bug#492086: partman: menus are very slow

[John Reiser <jreiser@BitWagon.com>]

Joey Hess wrote:

>>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.

I'm glad that you agree, because my results show that changing $PATH is
a 3.2% improvement for an environment quite similar to partman:
     ((22.2 - 21.5) / 22.2) = 0.0315
This is not "orders of magnitude" away from reality.
An speed improvement of 3.2% for very low implementation cost
is a much better than no improvement at all.

> 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.)

There was a "Hamilton C shell" for OS/2 that used builtin versions
of cat, cp, mv, ln, etc.  That shell ran rings around any other
with respect to execution speed of the typical shell script.


Partman runs very slowly.  It reflects poorly on debian-installer.
There are two implementable ideas that avoid fork+exec without requiring
a near-total re-implementation: non-literal variables, and 'read'.
"$(< file)" might be fixable in ash.  The bash shell directly supports
text menus with
     select name [ in word ] ; do list ; done
which apparently is not yet so portable to other shells.

Action, anybody?

--