Re: One more heap optimization trick for zsh < 5.2

[Bart Schaefer <schaefer@brasslantern.com>]

On May 16,  5:01pm, Sebastian Gniazdowski wrote:
} Subject: Re: One more heap optimization trick for zsh < 5.2
}
} I was testing the same input with 89k lines. The cause now
} accidentally clarified. It's about zplugin's shadowing of autoload

I was writing this off until I noticed that it's not just that the
first n-list takes a long time to begin, but that every motion in
the zcurses display takes a long time to update the viewport.

This means that it has to be something that's happening in the loop
inside the n-list function, affecting every iteration.

Consequently it must be one of n-list-input or n-list-draw, both of
which are declared with [the shadowed] autoload inside n-list itself.
Something about nesting calls to --zplg-reload-and-run is causing
the issue.  It might have something to do with retaining the old copy
of the function body until the call stack unwinds and it can safely
be freed; a large value for $argv would therefore also hang around
(two copies of it) for all of that time.

Incidentally, the way n-list is currently written, it will re-autoload
those functions and re-create all the _nlist_* helpers EVERY TIME IT
IS RUN.  Mostly that's all of no net effect, but it must be slowing
down each call to n-list at least a little bit.

Anyway, once n-list has run at least once, n-list-draw and n-list-input
are fully defined without --zplg-reload-and-run, so the slowdown during
the loop goes away.  I still don't know exactly *why* this would make
any difference, but a zprof pass *might* reveal something useful.