-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance improvements #52
Comments
Thanks for the issue and kind words!
To be clear, you're talking about time to first prompt right?
Looks like you have 47 abbreviations, is that right?
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.
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.) 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). |
ps tangentially, I'm interested to hear why you left Fish! |
For all intents and purposes, yes, essentially. New terminal tab, delay, prompt, start typing being the workflow.
LOL, I didn't really know until you mentioned it - I just pulled in what I used in Fish, but
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.
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.
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.
Performance tuning Zsh isn't my forte, but I may have look. My Zle widget experience is a bit light. Thanks for the reply! |
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 |
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. |
Relevant to the topic of deferred initialization and zsh startup speed:
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. |
@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. |
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.
If you use turbo mode in zinit instead of zsh-defer, the list of problems gets longer:
zsh-defer has one "advantage" over instant prompt: it reduces the time it takes to run |
Thank you for your work on this plugin! It's an essential one for me, coming from Fish. That said, it's also by far the slowest Zsh plugin I use and I was wondering if there's a performance tuning effort on the roadmap, if you've identified places where focusing on performance would have the biggest impact, or if you would accept PRs that address performance tuning?
When running
/usr/bin/time zsh -i -c exit
, my Zsh startup times jump from0.10 real 0.05 user 0.03 sys
to0.29 real 0.13 user 0.13 sys
when adding zsh-abbr. I use about 20 other plugins if that gives some context. Perhaps I'm spoiled by Fish's speed, but anything over .15 can feel really sluggish.I have had great luck loading this plugin via zsh-defer, which waits until Zle is idle to do the work of loading a plugin, thus getting you to a prompt quicker. My times then drop to
0.05 real 0.02 user 0.02 sys
. I think this is similar to what zinit does, but not everyone likes/uses zinit.An alternative to performance tuning the existing code might be to carve out the core concepts from zsh-defer and implement a mini-defer within zsh-abbr itself to accomplish the same thing without changing any other code. I'm happy to help, but don't want to go down the wrong path here if some thought has already gone into how to achieve better performance from this plugin.
Again, thank you so much for the work on this!
As a reference, this is my topline
zprof
results:The text was updated successfully, but these errors were encountered: