Re: math code optimisation

[hzoli@xxxxxxxxxx (Zoltan Hidvegi)]

Peter Stephenson <P.Stephenson@xxxxxxxxxxxxx> wrote:
> I just happened to look at mathevall() and noticed it was doing a lot
> of unncecessary memory moving, as well as keeping some stack space
> around when it wasn't using it.  Actual, tidying this up seems to make
> the code (OSF/1 3.0, using `size') 170 bytes larger, though there's
> less in data/bss, and it looked like it made about 8k difference
> (using `ps') at run time (which I don't understand since it should be
> about 1.5k, even with 64-bit longs; perhaps it's getting rounded up
> somewhere).

I'm quite busy recently and I had no time to response to mails. I hope it is
still not too late.

I'm not really sure that this optimisation Peter made in the quoted letter and
which is now part of beta9 is much better that the former code. While the
original code used the stack and memcpy, the current version uses
malloc/free. I agree that it should be a little faster than memcpy, but each
malloc may increase memory fragmentation and this way it may consume more
memory than necessary.

Probably that's the problem in other parts of the code, like in

% zsh -f
ktud% foo=( a{,}{,}{,}{,}{,}{,}{,}{,}{,}{,} )
ktud% ps aux $$
USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
hzoli     2237  3.6  3.6  460  556 pp0 S    17:03   0:00 zsh -f
ktud% echo ${foo%?}
 
ktud% ps aux $$    
USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
hzoli     2237  4.7 21.6 3168 3268 pp0 S    17:03   0:01 zsh -f
ktud% 

as you see, ${foo%?} above increases the resident size with about 2.7M the
first time it is executed (the exact reason for that is still unknown). This
happens on Linux with or wothout ZSH_MEM.

Because of this, I do not really like adding new malloc's. I think the math
code can use halloc if necessary which is safer and also does not requires
explicit free but it's probably better to use the stack and memcpy.

Zoltan