zsh-workers
 help / color / mirror / code / Atom feed
* Optimizing (z)-flag
@ 2019-08-11 18:20 Sebastian Gniazdowski
  2019-08-11 18:37 ` Bart Schaefer
  0 siblings, 1 reply; 3+ messages in thread
From: Sebastian Gniazdowski @ 2019-08-11 18:20 UTC (permalink / raw)
  To: Zsh hackers list

Hello,
I'm thinking: why the (z) flag runs significantly slower that a zsh
executing the same script / text? It points that the cause should be
the way that (z) stores resulting elements. I suspect that it in
general doesn't use realloc() to extend the destination array but
instead some kind of allocate new larger buffer / copy / free the
previous buffer. So the possible optimization could be to use realloc,
a method that has already been proven, as it is used when appending to
arrays.

Am I right? Where is the code of (z) flag aggregating the resulting
elements located? It's hard to find as it's somewhere between the
lex.c and subst.c.

The advantages of providing such optimization would span over e.g.
syntax-highlighting plugins.
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Optimizing (z)-flag
  2019-08-11 18:20 Optimizing (z)-flag Sebastian Gniazdowski
@ 2019-08-11 18:37 ` Bart Schaefer
  2019-08-11 19:20   ` Sebastian Gniazdowski
  0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2019-08-11 18:37 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Zsh hackers list

On Sun, Aug 11, 2019 at 11:21 AM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> I'm thinking: why the (z) flag runs significantly slower that a zsh
> executing the same script / text? It points that the cause should be
> the way that (z) stores resulting elements.

You're going to want to look at bufferwords in Src/hist.c.  If memory
allocation is the problem (of which I'm not convinced) it's probably
because the lexer discards some tokens while building the parse tree,
and bufferwords has to reconstruct the original text in some form,
which often means recopying the string values that the lexer does
return.  I don't think it's got very much to do with actually managing
the array, other than in the generic sense that parameter expansions
are done by value rather than by reference and therefore the source
array is copied yet again during final substitution.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Optimizing (z)-flag
  2019-08-11 18:37 ` Bart Schaefer
@ 2019-08-11 19:20   ` Sebastian Gniazdowski
  0 siblings, 0 replies; 3+ messages in thread
From: Sebastian Gniazdowski @ 2019-08-11 19:20 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On Sun, 11 Aug 2019 at 20:37, Bart Schaefer <schaefer@brasslantern.com> wrote:
> You're going to want to look at bufferwords in Src/hist.c.  If memory
> allocation is the problem (of which I'm not convinced) it's probably
> ...

Yeah, it does things properly – via a linked list. So appends are
fast. At the end it converts the list into an array via:
            aval = hlinklist2array(list, 0);

which does things properly too. I'm not sure why I've had the
impression that (z) is somewhat slow, for a zshrc with 20001
characters it runs in:

( a=(${(z)buff}) ; )  0,00s user 0,00s system 83% cpu 0,005 total

which is a very good time. It was probably when I was optimizing
fast-syntax-highlighting and a time like 100 ms seemed large.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-08-11 19:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-11 18:20 Optimizing (z)-flag Sebastian Gniazdowski
2019-08-11 18:37 ` Bart Schaefer
2019-08-11 19:20   ` Sebastian Gniazdowski

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).