Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Fwd: Re: Brace expansion performance



On 23/03/2010 5.18, Bart Schaefer wrote:
On Mar 22,  9:00pm, Radoulov, Dimitre wrote:
}
} It seams that it's that particular combination with the for loop:
}
} % strace -c zsh -fc 'for i in {1..1000}; do :;done'

[...]

} On 22/03/2010 18.22, Bart Schaefer wrote:
}>  I'm pretty sure zsh is actually allocating an array of 300000
}>  integers during expansion of that expression, and probably copying
}>  it a few times.
}
} Yes, thanks!
} Could this explain such a big difference in the timings?

Turns out that's not quite it.  Do you happen to know whether your zsh
is compiled with --enable-zsh-mem ?  With --enable-zsh-mem-debug ?


Zsh-mem was not enabled. Anyway, with enable-zsh-mem (on my notebook, Ubuntu on VirtualBox) I get similar timings.


If you look at "ltrace -c" instead of "strace" for that same 1000
integers, here's zsh:

% time     seconds  usecs/call     calls      function
------ ----------- ----------- --------- --------------------
  35.83    2.273416         403      5630 strlen
  35.59    2.258366         751      3006 sigprocmask
   6.55    0.415719          48      8594 memset
   4.67    0.296125          48      6055 memcpy
   3.78    0.239621          48      4964 strcmp
   3.57    0.226469          48      4630 mbrtowc
   3.48    0.220989          48      4556 strcpy
   1.55    0.098170          48      2004 fflush
   1.52    0.096682          48      2004 __errno_location
   0.93    0.059187          48      1221 strchr
   0.80    0.050600          50      1001 sprintf
   0.76    0.048399          48      1001 ferror
   0.76    0.048374          48      1000 strcat
(snipped)

And here's bash:

% time     seconds  usecs/call     calls      function
------ ----------- ----------- --------- --------------------
  29.58    3.282781         124     26449 malloc
  29.39    3.261934         125     25933 free
  25.14    2.790494         171     16238 strcpy
   5.14    0.570544          48     11695 __ctype_get_mb_cur_max
   4.83    0.536449          48     11012 memcpy
   2.67    0.295913          48      6101 strcmp
   2.20    0.244207          48      5003 strchr
   0.44    0.048769          48      1002 memset
   0.44    0.048475          48      1000 ferror
   0.08    0.008553        8553         1 qsort
   0.03    0.002880          48        59 mbrtowc
   0.01    0.000828          48        17 sigemptyset
   0.01    0.000698          87         8 sigaction
(snipped)

Note that bash does significantly more calls to malloc/free, but
does much less signal handling -- and doesn't use stdio at all; and
zsh is spending a lot of calls zeroing out memory and doing multibyte
conversion, which bash doesn't do anywhere near as often.  I suspect
this is down to whether the shell stores things in native multibyte
internally or not.

However, for smaller loops I tried, zsh was consistently faster --
it's not until you approach six digits of loop bound that zsh begins
to fall behind, at least on my hardware.  So I think this is a case
of the shells having optimized for different things, and for what I'd
presume are the more common cases, zsh does just fine.

Thank you for the explanation.



Regards
Dimitre



Messages sorted by: Reverse Date, Date, Thread, Author