Re: Fwd: Re: Brace expansion performance

["Radoulov, Dimitre" <cichomitiko@xxxxxxxxx>]

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