Re: Slowdown around 5.0.5-dev-0

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

Turns out I read this correctly for the first time. You meant 36926,
which is the yesterday's patch. Having this in mind my email still
makes sense. I just described how 36834, 36836, 36926 behave.

On 24 October 2015 at 09:37, Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
> On 24 October 2015 at 08:09, Sebastian Gniazdowski
> <sgniazdowski@xxxxxxxxx> wrote:
>> On 24 October 2015 at 01:50, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>>> On Oct 23, 12:26pm, Bart Schaefer wrote:
>>> }
>>> } Try the below patch against 8e9a68ad1 ?
>>>
>>> However, if the results can be considered reliable anyway, note that
>>> 36926 retains most of the search_test speed, which I think is an
>>> improvement over backing out all of 36834 (Sebastian's results for
>>> zsh-newheaps-zhalloc, if I'm reading his email correctly).
>>
>> I ran quick tests yesterday and obtained this too. Good news that not
>> all gains of 36834 will be withdrawn! :) The newheaps-zhalloc is what
>> you write, two following patches without 36834.
>
> I misread this. What I wanted to state, is that your patch from
> yesterday retained search_test speed.
>
> The fact that 36836 has its contribution in speeding up search_test is
> was described by me in previous email:
>
>> newheaps is responsible for
>> instant-responsivity of my script, 36836 for much faster searching –
>> that's a good compromise
>
> So the thing is that your patch from yesterday retains search_test
> speed up of 36834, while fixing the memory issues of 36834. Together
> with 36836, this gives full retain of search_test speedup, nothing is
> lost, speed of pattern matching is as high as with no revert from
> current head state. What's lost is string_test speedup 36834 gave,
> however, it did so with cost of increased memory usage
>
> Best regards,
> Sebastian Gniazdowski