On 01/07/2011 08:39 AM, Chet Ramey wrote: > On 1/7/11 10:03 AM, Chet Ramey wrote: >> On 1/6/11 8:17 PM, Alexander Tiurin wrote: >>> Hi! >>> >>> I ran the command >>> >>> ~$ time for i in `seq 0 10000` ; do echo /o/23/4 | cut -d'/' -f2 ; done >>>> /dev/null >>> >>> 6 times in a row, and noticed to the increase in execution time: >>> >> [...] >>> >>> how to interpret the results? >> >> It's hard to say without doing more investigation, but I suspect that the >> fork time is increasing because the bash binary is growing in size. >> >> I'd have to build a version with profiling enabled to tell for sure. > > I built a profiling version of bash-4.2 (without the bash malloc, since > linux doesn't let you replace malloc when you're profiling), and the > execution time was dominated by fork: around 55-60% of the time. That's > around 10-15 times more than any other function.
Is it time to use posix_spawn() instead of fork() in the cases where we are spawning external processes? It doesn't help the fact that we have to still use fork() for subshells, but as the bash binary grows larger, posix_spawn() becomes more of a win over fork() by reducing kernel overhead spent in marking a larger memory footprint as copy-on-write, when that work is later discarded by an exec(). -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
