zsh-users
 help / color / mirror / code / Atom feed
* New zplugin feature (was: Re: How completions work, do they require fpath?)
@ 2016-02-10  9:08 Sebastian Gniazdowski
  2016-02-10  9:19 ` Sebastian Gniazdowski
  0 siblings, 1 reply; 3+ messages in thread
From: Sebastian Gniazdowski @ 2016-02-10  9:08 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

On 31 January 2016 at 20:26, Bart Schaefer <schaefer@brasslantern.com> wrote:
> You could try this:  Define your own "compdef" whose only action is
> to cache its arguments somewhere.  Load all the plugins, then after
> compinit is run, play back the cached compdef arguments with the real
> compdef.

I realized how great that idea is. Implemented it in zplugin, thus an
idiom is possible:

source '/Users/sgniazdowski/.zplugin/bin/zplugin.zsh'
zplugin load "some1/plugin1"
zplugin load "some2/plugin2"
...
zplugin load "some3/plugin3"
autoload -Uz compinit
compinit
zplugin cdreplay -q # -q is quiet

The difference between running compinit once and twice is huge,
following time differences are possible:
zsh -i -c exit  0,73s user 0,25s system 99% cpu 0,980 total
zsh -i -c exit  0,11s user 0,04s system 97% cpu 0,156 total
(for 3 plugins)
zsh -i -c exit  1,24s user 0,41s system 99% cpu 1,667 total
zsh -i -c exit  0,48s user 0,18s system 98% cpu 0,668 total
(for 40 plugins)

This is a very innovative, great thing. All current plugin managers
drifted towards double compinit calling, by force of lack of
shadowing:
https://github.com/tarjoilija/zgen/blob/master/zgen.zsh#L471-L475
https://github.com/zsh-users/antigen/blob/master/antigen.zsh#L441-L462

OMZ slowness is I guess also result of this.

Fun example:
% unfunction compdef
% zplg dtrace
% compdef _ls cp
% zplg dstop
% zplg cdlist
Recorded compdefs:
compdef _ls cp
% zplg cdreplay
Compinit isn't loaded, cannot do compdef replay
% autoload -Uz compinit
% compinit
% zplg cdreplay
Running compdef _ls cp
% echo $_comps[cp]
_ls

Best regards,
Sebastian Gniazdowski


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

* Re: New zplugin feature (was: Re: How completions work, do they require fpath?)
  2016-02-10  9:08 New zplugin feature (was: Re: How completions work, do they require fpath?) Sebastian Gniazdowski
@ 2016-02-10  9:19 ` Sebastian Gniazdowski
  2016-02-10 13:15   ` Sebastian Gniazdowski
  0 siblings, 1 reply; 3+ messages in thread
From: Sebastian Gniazdowski @ 2016-02-10  9:19 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

Well, actually, antigen snippet I showed implements this too :D In
Advanced Bash Scripting Guide style (thus not fast), but still, they
do it.

Best regards,
Sebastian Gniazdowski


On 10 February 2016 at 10:08, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> On 31 January 2016 at 20:26, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> You could try this:  Define your own "compdef" whose only action is
>> to cache its arguments somewhere.  Load all the plugins, then after
>> compinit is run, play back the cached compdef arguments with the real
>> compdef.
>
> I realized how great that idea is. Implemented it in zplugin, thus an
> idiom is possible:
>
> source '/Users/sgniazdowski/.zplugin/bin/zplugin.zsh'
> zplugin load "some1/plugin1"
> zplugin load "some2/plugin2"
> ...
> zplugin load "some3/plugin3"
> autoload -Uz compinit
> compinit
> zplugin cdreplay -q # -q is quiet
>
> The difference between running compinit once and twice is huge,
> following time differences are possible:
> zsh -i -c exit  0,73s user 0,25s system 99% cpu 0,980 total
> zsh -i -c exit  0,11s user 0,04s system 97% cpu 0,156 total
> (for 3 plugins)
> zsh -i -c exit  1,24s user 0,41s system 99% cpu 1,667 total
> zsh -i -c exit  0,48s user 0,18s system 98% cpu 0,668 total
> (for 40 plugins)
>
> This is a very innovative, great thing. All current plugin managers
> drifted towards double compinit calling, by force of lack of
> shadowing:
> https://github.com/tarjoilija/zgen/blob/master/zgen.zsh#L471-L475
> https://github.com/zsh-users/antigen/blob/master/antigen.zsh#L441-L462
>
> OMZ slowness is I guess also result of this.
>
> Fun example:
> % unfunction compdef
> % zplg dtrace
> % compdef _ls cp
> % zplg dstop
> % zplg cdlist
> Recorded compdefs:
> compdef _ls cp
> % zplg cdreplay
> Compinit isn't loaded, cannot do compdef replay
> % autoload -Uz compinit
> % compinit
> % zplg cdreplay
> Running compdef _ls cp
> % echo $_comps[cp]
> _ls
>
> Best regards,
> Sebastian Gniazdowski


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

* Re: New zplugin feature (was: Re: How completions work, do they require fpath?)
  2016-02-10  9:19 ` Sebastian Gniazdowski
@ 2016-02-10 13:15   ` Sebastian Gniazdowski
  0 siblings, 0 replies; 3+ messages in thread
From: Sebastian Gniazdowski @ 2016-02-10 13:15 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh Users

Just to illustrate how ABS style programming (it's probably it)
influences performance – for the same 40 plugins antigen takes 4.906
sec, instead of 0.668 sec. That's with zplugin's "debug" loading, with
light loading (only autoload and compdef are then shadowed) it's 0.326
sec, the same for zgen (compinit called once).

Best regards,
Sebastian Gniazdowski

On 10 February 2016 at 10:19, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Well, actually, antigen snippet I showed implements this too :D In
> Advanced Bash Scripting Guide style (thus not fast), but still, they
> do it.
>
> Best regards,
> Sebastian Gniazdowski
>
>
> On 10 February 2016 at 10:08, Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
>> On 31 January 2016 at 20:26, Bart Schaefer <schaefer@brasslantern.com> wrote:
>>> You could try this:  Define your own "compdef" whose only action is
>>> to cache its arguments somewhere.  Load all the plugins, then after
>>> compinit is run, play back the cached compdef arguments with the real
>>> compdef.
>>
>> I realized how great that idea is. Implemented it in zplugin, thus an
>> idiom is possible:
>>
>> source '/Users/sgniazdowski/.zplugin/bin/zplugin.zsh'
>> zplugin load "some1/plugin1"
>> zplugin load "some2/plugin2"
>> ...
>> zplugin load "some3/plugin3"
>> autoload -Uz compinit
>> compinit
>> zplugin cdreplay -q # -q is quiet
>>
>> The difference between running compinit once and twice is huge,
>> following time differences are possible:
>> zsh -i -c exit  0,73s user 0,25s system 99% cpu 0,980 total
>> zsh -i -c exit  0,11s user 0,04s system 97% cpu 0,156 total
>> (for 3 plugins)
>> zsh -i -c exit  1,24s user 0,41s system 99% cpu 1,667 total
>> zsh -i -c exit  0,48s user 0,18s system 98% cpu 0,668 total
>> (for 40 plugins)
>>
>> This is a very innovative, great thing. All current plugin managers
>> drifted towards double compinit calling, by force of lack of
>> shadowing:
>> https://github.com/tarjoilija/zgen/blob/master/zgen.zsh#L471-L475
>> https://github.com/zsh-users/antigen/blob/master/antigen.zsh#L441-L462
>>
>> OMZ slowness is I guess also result of this.
>>
>> Fun example:
>> % unfunction compdef
>> % zplg dtrace
>> % compdef _ls cp
>> % zplg dstop
>> % zplg cdlist
>> Recorded compdefs:
>> compdef _ls cp
>> % zplg cdreplay
>> Compinit isn't loaded, cannot do compdef replay
>> % autoload -Uz compinit
>> % compinit
>> % zplg cdreplay
>> Running compdef _ls cp
>> % echo $_comps[cp]
>> _ls
>>
>> Best regards,
>> Sebastian Gniazdowski


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

end of thread, other threads:[~2016-02-10 13:15 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-10  9:08 New zplugin feature (was: Re: How completions work, do they require fpath?) Sebastian Gniazdowski
2016-02-10  9:19 ` Sebastian Gniazdowski
2016-02-10 13:15   ` 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).