Re: Slowdown around 5.0.5-dev-0

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

As for the code, it's interesting that it is just existence of large
array that slows down things. Just before spotting the >=5.0.5
slowdown I wrote an optimization:

        if [ "$prev_start_idx" -ne "$NLIST_FROM_WHAT_IDX_LIST_IS_SHOWN" ]; then
            prev_start_idx="$NLIST_FROM_WHAT_IDX_LIST_IS_SHOWN"
            disp_list=(
"${(@)col_list[NLIST_FROM_WHAT_IDX_LIST_IS_SHOWN, end_idx]}" )
        fi

It creates a small array disp_list that is used for display. 23
elements in my case. The large 89k array "sleeps" waiting for change
of page or some other trigger (details not important). The patch
helped for 5.0.2 (except the possible temporal "dig" into slowness)
but for >= 5.0.5 it helps just a little, while it should help
completely, as everything is around 23 elements long array.

Best regards,
Sebastian Gniazdowski


On 10 October 2015 at 20:11, Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
> On 10 October 2015 at 19:58, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>> On the other hand the shell really isn't intended to be manipulating
>> arrays of containing tens of thousands of elements.
>
> I was afraid that this will be stated, by you as the author of the
> patch. It's just such a great thing that patterns are so fast, faster
> than regular expressions (from zsh/regex). And that they are so
> advanced. I can do fancy things like filtering for multiple words with
> *foo*~^*bar*, colorizing output by using (#m) which is faster than
> (#b) and provided for someone aware to utilize that gain and
> functionality. What I mean is that we shouldn't now slip into "shell
> isn't for that, anyway" after providing so much.
>
> PS. Not everything is so great, I was successfully optimizing my code
> by changing if[] into [] && || in crucial places. Removing variables
> as even a single assignment seems to cost much. But overall there's
> plenty in speed and functionality.
>
> Best regards,
> Sebastian Gniazdowski