Re: Slowdown around 5.0.5-dev-0

[Sebastian Gniazdowski <sgniazdowski@gmail.com>]

On 22 October 2015 at 17:00, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Oct 22,  2:49pm, Sebastian Gniazdowski wrote:
> }
> } My conclusions:
> } - 36834 introduces high memory usage; I would suggest to use only two
> } optimizations -- newheaps and zhalloc; my znavtools are instant fast
> } with them, what's slower is searching (wrote search_test function,
> } results attached)
>
> My apologies, but I'm not sure I followed all of that.  Can you produce
> a diff against commit 8e9a68ad14655c1949b1a04d5715a5caa8c344ee that
> shows the situation you think is the best so far?

Patch 9f8e3e8 (36834) and 643aca9 (lost part of 36834) needs to be
reverted. The patches that should stay are 36836 (nicknamed zhalloc by
me) and 36853 (nicknamed newheaps). 9f8e3e8 doesn't revert
automatically, I can probably do it later if you won't.

> } - newheaps makes function calls longer, but it's not a substantial
> } difference
>
> 14% is pretty substantial, but it's probably all gained back if the
> function does anything significant with local variables.

Yes, I strongly looked forward at instant responsivity ignoring the
loss. Wanted to do some real world test – find fully zsh-based
distribution, switch Zsh between newheaps version and no-newheaps
version, compare boot times, but there isn't such distribution. Peter
described one possible real world test, but not sure how to do it, I
might think about it again.

Function calls aren't that fast anyway, are they? When optimizing ZNT
I pasted an expand_tabs() function instead of calling it 30k times
because even with the body of the function literally empty, zprof
still reported 10-15% use of CPU time. I might later revert ZNT to
that commit to compare how this behaves now, it might be surprisingly
better than worse.

Best regards,
Sebastian Gniazdowski