53489107
by наб at 2023-06-17T11:04:31+02:00
Parallelise locale-gen if possible
Assuming a very generous 200M free/localedef (because I saw a max RSS
of 147M w/time(1)), this will attempt to keep all jobs saturated,
and usually succeed. There's little starvation, since the vast majority
of time is spent in gzip(1) ‒ 1:14 user vs 27:55 sys
At 2.2ish seconds per locale, even on a low-end system of today with
4 CPUs (and 800 free MB), we can generate up to 4 locales at once
for 6.6s' speed-up. Assuming no super-pathological cases, this globally
scales in roughly ceil(locales/ncpus)*2.2s chunks, which is a massive
win
The only user-visible change is that, with nproc>1, the output is
en_GB.UTF-8...
<cursor here>
instead of
en_GB.UTF-8... <cursor here, will print "done\n" when it's done>
MemFree: in /proc/meminfo is available on all supported Debian kernels,
MemAvailable: only on Linux; procps free(1) uses MemAvailable to
estimate "used" space where available.