Render the non-bash srandom() implementation faster

Presently, there are three implementations of srandom(), one of which is
the preferred implementation for shells other than bash. It is a little
on the slow side as it has to fork and execute both od(1) and tr(1)
every time, just to read 4 bytes. Accelerate it by having the shell
maintain its own entropy pool of up to 512 hex digits in size. Consider
the following benchmark.

i=0; while [ $((i += 1)) -le 30000 ]; do srandom; done >/dev/null

As conducted with dash on a system with a 2nd generation Intel Xeon, I
obtained the following figures.

BEFORE

real    0m49.878s
use     1m1.985s
sys     0m17.035s

AFTER

real    0m12.866s
user    0m12.559s
sys     0m0.962s

It should be noted that the optimised routine will only be utilised in
cases where the kernel is Linux and the shell has not forked itself.

$ uname
Linux
$ srandom                       # uses the fast path
$ number=$(srandom)             # subshell; probably uses the slow path
$ srandom | { read -r number; } # ditto

Still, there are conceivable use cases for which this optimisation may
prove useful. Below is an example in which it is known in advance that
up to 100 random numbers are required, and where writing them to
temporary storage is not considered to be a risk.

i=0
tmpfile=${TMPDIR:-/tmp}/random-numbers.$$.$(srandom)
while [ $((i += 1)) -le 100 ]; do
	srandom
done > "$tmpfile"
while read -r number; do
	do_something_with "$number"
done < "$tmpfile"

Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>

0 files changed, 0 insertions, 0 deletions