Jody Bruchon wrote:
>It is definitely interesting. The problem from my perspective is that
>the potential performance drop is way too high. On platforms where 500
>bytes matter, chances are that CPU power is also very limited. This
>increases the fork cost when any BusyBox applet is invoked, meaning
>shell scripts will be much slower.
find_applet_by_name() is only a small part of what's involved in starting
an applet.
I've done some tests which record the elapsed time between the point
in the shell where it's determined that a command needs to be run (the
comment 'Now locate the command' in evalcommand()) and the start
of the main applet function for the basename, od and uname applets.
I've considered three cases:
Before my change to reduce the number of known offsets (9844d7e)
After that change was introduced (b220617)
Denys's tweaked version of the current patch
With the default configuration the average elapsed time in microseconds
for 10,000 iterations on my Core i5 are:
9844d7e b220617 Patch
basename 322.273 314.882 315.582
od 317.780 313.696 313.974
uname 316.005 308.554 311.568
In standalone shell mode basename doesn't require a fork and the
number of iterations had to be increased to 3,000,000:
9844d7e b220617 Patch
basename 1.126 1.175 1.358
od 321.948 319.578 321.870
uname 317.021 319.718 321.966
When a fork is involved the effect of the changes to find_applet_by_name()
is lost in the noise. For a NOFORK applet in standalone shell mode the
changes result in a slight increase in start up time.
Ron
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
