Performance improvements about zsh-abbr

[mattmc3]

To be clear, you're talking about time to first prompt right?

For all intents and purposes, yes, essentially. New terminal tab, delay, prompt, start typing being the workflow.

Looks like you have 47 abbreviations, is that right?

LOL, I didn't really know until you mentioned it - I just pulled in what I used in Fish, but wc -l $ZDOTDIR/abbreviations confirms 47!

I expect you bring zinit up because of its appearance in the readme's performance section

Yes, that and zsh-defer references it too. It's one performance avenue, though you're right - anyone that came to rely too heavily on zinit got burned.

Would you share your zsh-defer implementation

Happy to. Here's is my (perhaps too clever) plugin loading snippet. Plugins that show up before zsh-defer are sourced normally. Ones after will always use zsh-defer.

# github plugins list
plugins=(
  zshzoo/zshrc.d
  romkatv/zsh-defer
  zshzoo/setopts
  zshzoo/history
  zshzoo/keybindings
  zshzoo/zstyle-completions
  zsh-users/zsh-autosuggestions
  zsh-users/zsh-history-substring-search
  mattmc3/zman
  olets/zsh-abbr
  zshzoo/copier
  zshzoo/macos
  zshzoo/prj
  zshzoo/magic-enter
  zshzoo/zfishcmds
  zshzoo/termtitle
  rupa/z
  rummik/zsh-tailf
  peterhurford/up.zsh
  zshzoo/compinit
  zdharma-continuum/fast-syntax-highlighting
)
# clone and source plugins, using zsh-defer if it exists
for repo in $plugins; do
  plugin_dir=$ZDOTDIR/plugins/${repo:t}
  initfile=$plugin_dir/${repo:t}.plugin.zsh
  [[ -d $plugin_dir ]] \
    || git clone --depth 1 --recursive --shallow-submodules https://github.com/$repo $plugin_dir
  if [[ ! -e $initfile ]]; then
    initfiles=($plugin_dir/*.plugin.{z,}sh(N) $plugin_dir/*.{z,}sh(N))
    ln -s "${initfiles[1]}" "$initfile"
  fi
  fpath+=$plugin_dir
  if (( $+functions[zsh-defer] )); then
    zsh-defer source $initfile
  else
    source $initfile
  fi
done

I pretty much have the speed I need with this setup (it's crazy fast!), but since others use plugin managers, they'd probably only get the benefit if zsh-abbr got faster or if their plugin manager has defer.

ps tangentially, I'm interested to hear why you left Fish!

I didn't leave it as much as it's just not available on every system I use, and context switching can be tiring. I (obviously) spend entirely too much time making Zsh behave like Fish so it feels more like home.

If you want to take a crack at that go for it

Performance tuning Zsh isn't my forte, but I may have look. My Zle widget experience is a bit light. Thanks for the reply!

[olets]

Thanks for sharing your setup!

Thought about this some more, and I can't think of a way I'm happy with. Much better than my above idea would be to let users opt out of loading abbreviations from the user abbreviation file during initialization, but that feels like configuration variable bloat with the new risk that users could lose data (in a way the user would be responsible for, but still it makes me uncomfortable). The idea I proposed earlier has the same risk, plus extra files. So I think relying on an outside solution for async is the way to go.

I've released v4.7.0 with two changes inspired by your zprof output: _abbr_no_color is now only called once during initialization, and _abbr_deprecations:widgets is much faster.

[olets]

Thanks for the issue and kind words!

by far the slowest Zsh plugin I use

To be clear, you're talking about time to first prompt right?

my topline zprof results

Looks like you have 47 abbreviations, is that right?

not everyone likes/uses [zinit].

I expect you bring zinit up because of its appearance in the readme's performance section. As of this I no longer recommend zinit myself.

I have had great luck loading this plugin via zsh-defer
I think this is similar to what zinit does
don't want to go down the wrong path here

Would you share your zsh-defer implementation? Others might come across this conversation and appreciate it.

I don't see zsh-abbr having built-in async loading. I personally would rather have a delay than have an abbreviation not expand; zsh-defer and other async solutions make it possible for individuals to choose to load it async.

After wrapping up #32 / #49 I don't plan to do major feature development on zsh-abbr any time soon. Without a major overhaul to how zsh-abbr's initialization works, I don't think it'll ever get really fast. (As suggested by your zprof output, it essentially runs each abbr command in the user abbreviations file.) I suppose the overhaul could be that the intermediary typeset -p output is saved in a permanent location next to the current user abbreviation file, instead of in temp files, and then initialization reads those arrays and does a single user file sync at the end. Not sure it'd be worth cluttering up the dotfiles with two extra files. If you want to take a crack at that go for it! The branch v5 is the one to work off. As with all open source, can't promise it'll merge — feel free to open a wip PR, or chat about design here. (I won't be on GitHub much in the next month though) edit: I no longer like this idea, see further down in the conversation for details

For now I think lazy loading the plugin is going to be your best bet — with zsh-defer, or with a plugin manager that has lazy loading support (from their readmes, at least zcomet, zgenom, znap, and zplug have lazy loading features. I haven't experimented with them).

[olets]

ps tangentially, I'm interested to hear why you left Fish!

[mattmc3]

Awesome! Thanks for looking into it. If anyone else runs into performance questions in the future, hopefully they'll find this thread and get some ideas. As long as zsh-abbr continues to play nice with zsh-defer, I'm good on my end. Thanks again.

[romkatv]

Relevant to the topic of deferred initialization and zsh startup speed:

• https://github.com/romkatv/zsh-bench#deferred-initialization
• https://github.com/romkatv/zsh-bench#how-not-to-benchmark

zsh-defer implements deferred initialization better than zinit (or any other project I know of) but I still don't recommend it.

Disclaimer: I'm the author of zsh-defer.

[mattmc3]

@romkatv - is there an initialization speed up strategy you do recommend? The only side effect I've observed from my (albeit very recent and limited) use of zsh-defer is occasionally the first command may lack some plugin features due to not having completed the deferred init. That's the compromise olets rightly calls out being a non-starter for zsh-abbr on the whole, but not one I've in practice had actually hurt my setup. I'd have to type a short abbr really fast for it not to expand.

[romkatv]

If your goal is to reduce first prompt lag, something like instant prompt is the best solution I know of. It's strictly better than zsh-defer and by a large margin.

• Instant prompt shows prompt faster.
• Instant prompt doesn't require changes in zshrc other than adding a few lines at the top.
• Instant prompt doesn't break plugins. zsh-defer is able to load zsh-syntax-highlighting and zsh-autosuggestions only because it implements specific hacks for these plugins. In general you'll have to implement and maintain such hacks for the plugins you want to load. Even if some plugin appears to be compatible with zsh-defer today, it may break tomorrow. Virtually no plugins guarantee that it's OK to load them from zle.
• Instant prompt doesn't let zle process keystrokes while zsh is still initializing. The fact that zsh-defer essentially does random things for some time after you start zsh is the biggest problem of all. If you press TAB before completions are initialized, you'll get unexpected completions; press UP before history is initialized and get unexpected history. Press ENTER before aliases are set and get wrong command. Etc.
• Both instant prompt and zsh-defer disallow plugins from reading the TTY and printing to it during initialization. However, instant prompt handles violations much more gracefully. zsh-defer offers only two options: let plugins break zle or send their output to /dev/null.

If you use turbo mode in zinit instead of zsh-defer, the list of problems gets longer:

• Overall initialization time increases substantially. The overhead of zinit is more than an order of magnitude greater than zsh-defer.
• During initialization zle will non-deterministically freeze and stop processing input.

zsh-defer has one "advantage" over instant prompt: it reduces the time it takes to run zsh -c exit. If that's something you care about, https://github.com/romkatv/you-the-champ is even better at this job and has no other effects.