Instantly share code, notes, and snippets.

Embed
What would you like to do?
The slowness of my zsh prompt when in a git-svn managed directory was killing me. I improved it by removing the git status stuff that slows it down...
function git_prompt_info() {
ref=$(git symbolic-ref HEAD 2> /dev/null) || return
echo "$ZSH_THEME_GIT_PROMPT_PREFIX${ref#refs/heads/}$ZSH_THEME_GIT_PROMPT_SUFFIX"
}
@rbugajewski

This comment has been minimized.

Show comment
Hide comment
@rbugajewski

rbugajewski Nov 13, 2012

In my theme (robbyrussell) I was missing the ending brace, so I changed the output to echo "$ZSH_THEME_GIT_PROMPT_PREFIX${ref#refs/heads/}${ZSH_THEME_GIT_PROMPT_CLEAN}${ZSH_THEME_GIT_PROMPT_SUFFIX}".

rbugajewski commented Nov 13, 2012

In my theme (robbyrussell) I was missing the ending brace, so I changed the output to echo "$ZSH_THEME_GIT_PROMPT_PREFIX${ref#refs/heads/}${ZSH_THEME_GIT_PROMPT_CLEAN}${ZSH_THEME_GIT_PROMPT_SUFFIX}".

@toc21c

This comment has been minimized.

Show comment
Hide comment
@toc21c

toc21c Apr 10, 2013

awesome!!

toc21c commented Apr 10, 2013

awesome!!

@akilman-zz

This comment has been minimized.

Show comment
Hide comment
@akilman-zz

akilman-zz May 7, 2013

This has been bugging me for some time now. Thanks!

akilman-zz commented May 7, 2013

This has been bugging me for some time now. Thanks!

@admdikramr

This comment has been minimized.

Show comment
Hide comment
@admdikramr

admdikramr Jun 6, 2013

This is excellent -- but when I'm not in a git directory, it says (master). Is there an easy way to prevent this?

admdikramr commented Jun 6, 2013

This is excellent -- but when I'm not in a git directory, it says (master). Is there an easy way to prevent this?

@rajsahae

This comment has been minimized.

Show comment
Hide comment
@rajsahae

rajsahae Sep 19, 2013

Huge huge help. Thank you.

rajsahae commented Sep 19, 2013

Huge huge help. Thank you.

@gferon

This comment has been minimized.

Show comment
Hide comment
@gferon

gferon Oct 22, 2013

I think you should submit a pull request with this fix, so it can be toggled with a setting!

gferon commented Oct 22, 2013

I think you should submit a pull request with this fix, so it can be toggled with a setting!

@rekendahl

This comment has been minimized.

Show comment
Hide comment
@rekendahl

rekendahl Jan 7, 2014

Thank you. This has been bugging me under CentOS 6 for some time. It is true that what's slow on my system is git status. I wonder if it's a git version thing (CentOS runs a older version) or it it's a git svn thing.

rekendahl commented Jan 7, 2014

Thank you. This has been bugging me under CentOS 6 for some time. It is true that what's slow on my system is git status. I wonder if it's a git version thing (CentOS runs a older version) or it it's a git svn thing.

@messick

This comment has been minimized.

Show comment
Hide comment
@messick

messick commented Aug 12, 2014

👍

@jbnunn

This comment has been minimized.

Show comment
Hide comment
@jbnunn

jbnunn Sep 3, 2014

Works on Yosemite as well--thank you!

jbnunn commented Sep 3, 2014

Works on Yosemite as well--thank you!

@n1k0

This comment has been minimized.

Show comment
Hide comment
@n1k0

n1k0 Sep 8, 2014

Just to add a thank you to the stack. Cheers!

n1k0 commented Sep 8, 2014

Just to add a thank you to the stack. Cheers!

@kstach01

This comment has been minimized.

Show comment
Hide comment
@kstach01

kstach01 Oct 15, 2014

Thanks! That was driving me insane.

kstach01 commented Oct 15, 2014

Thanks! That was driving me insane.

@yonatankarni

This comment has been minimized.

Show comment
Hide comment
@yonatankarni

yonatankarni Jan 20, 2015

great stuff! thanks!

yonatankarni commented Jan 20, 2015

great stuff! thanks!

@justinharringa

This comment has been minimized.

Show comment
Hide comment
@justinharringa

justinharringa commented Feb 9, 2015

👍

@retgoat

This comment has been minimized.

Show comment
Hide comment
@retgoat

retgoat Apr 23, 2015

Works great! Thanks!

retgoat commented Apr 23, 2015

Works great! Thanks!

@kwketh

This comment has been minimized.

Show comment
Hide comment
@kwketh

kwketh May 22, 2015

Thanks, that looks great.
If anybody is still running into issues, you may trace all commands with set -o xtrace, you will see full context and likely which command may be taking long time. It helped me trace my problem.

kwketh commented May 22, 2015

Thanks, that looks great.
If anybody is still running into issues, you may trace all commands with set -o xtrace, you will see full context and likely which command may be taking long time. It helped me trace my problem.

@pmalek

This comment has been minimized.

Show comment
Hide comment
@pmalek

pmalek May 29, 2015

@kwketh How to undo set -o xtrace?

pmalek commented May 29, 2015

@kwketh How to undo set -o xtrace?

@pmalek

This comment has been minimized.

Show comment
Hide comment
@pmalek

pmalek May 29, 2015

After applying this fix I am missing the * (when I have midified working tree).

pmalek commented May 29, 2015

After applying this fix I am missing the * (when I have midified working tree).

@minhoryang

This comment has been minimized.

Show comment
Hide comment
@minhoryang

minhoryang Oct 3, 2015

HAPPY TO MEET YOU!

minhoryang commented Oct 3, 2015

HAPPY TO MEET YOU!

@SSchnitzler

This comment has been minimized.

Show comment
Hide comment
@SSchnitzler

SSchnitzler Oct 23, 2015

Thank you for this gist, it made working with zsh possible again for me as it was just unusably slow and i had to disable it again.

SSchnitzler commented Oct 23, 2015

Thank you for this gist, it made working with zsh possible again for me as it was just unusably slow and i had to disable it again.

@songcy6202

This comment has been minimized.

Show comment
Hide comment
@songcy6202

songcy6202 Dec 16, 2015

That's great ,thanks a lot.

songcy6202 commented Dec 16, 2015

That's great ,thanks a lot.

@smeggingsmegger

This comment has been minimized.

Show comment
Hide comment
@smeggingsmegger

smeggingsmegger Dec 29, 2015

Still relevant and wonderful. Thanks!

smeggingsmegger commented Dec 29, 2015

Still relevant and wonderful. Thanks!

@triadsk

This comment has been minimized.

Show comment
Hide comment
@triadsk

triadsk Jan 2, 2016

That worked, thanks a lot!

triadsk commented Jan 2, 2016

That worked, thanks a lot!

@HandIeNeeded

This comment has been minimized.

Show comment
Hide comment
@HandIeNeeded

HandIeNeeded commented Jan 5, 2016

Awesome!

@xiaoyang4011

This comment has been minimized.

Show comment
Hide comment
@xiaoyang4011

xiaoyang4011 commented Jan 16, 2016

nice!

@usmanayubsh

This comment has been minimized.

Show comment
Hide comment
@usmanayubsh

usmanayubsh Jan 28, 2016

Works like a charm! Thank you so much.

usmanayubsh commented Jan 28, 2016

Works like a charm! Thank you so much.

@dannykopping

This comment has been minimized.

Show comment
Hide comment
@dannykopping

dannykopping commented May 8, 2016

👍

@harukaeru

This comment has been minimized.

Show comment
Hide comment
@harukaeru

harukaeru commented Oct 19, 2016

Great!

@smo0f

This comment has been minimized.

Show comment
Hide comment
@smo0f

smo0f Nov 11, 2016

@pmalek to undo set -o xtrace, run set +o xtrace - plus instead of minus

smo0f commented Nov 11, 2016

@pmalek to undo set -o xtrace, run set +o xtrace - plus instead of minus

@jep-dev

This comment has been minimized.

Show comment
Hide comment
@jep-dev

jep-dev Oct 29, 2017

In my case, this didn't noticeably improve the delay. It has all the same symptoms (no delay outside of Git repo; delay for anything that causes a new prompt to draw, like hitting enter on an empty line, <ctrl+l>, etc.; no delay pressing other keys or while a command is still running.) This does not appear to be related to my network speed. I could post my versions, config files, etc. but I'd like to look find more general alternative approaches first.

For what it's worth, I'm using bhilburn/powerlevel9k with submodule checking disabled, effectively --ignore-submodules=dirty (not that the project I'm testing on has submodules anyway - more complicated projects I've cloned take much longer.)

Would it be possible to set a flag or add a sentinel file somewhere to indicate if/when the local status has actually changed? Maybe caching the command's output and using the cached version if the (parent) directory's modified date is within some threshold of the cache, or if the cache is similarly recent compared to the current time? The worst effects if it malfunctions should be saving the output every time (negligible contribution to original delay) or showing an outdated status, and both should be fixed by re-tuning the threshold, and of course excluding the cache file via .gitignore.

A few benchmarks for reference...
I can't seem to use the time command on git_prompt_info, but 500 iterations of the command (piped to /dev/null; book-ended by date) averaged to 26ms each.
Timing git add -An and git status with the same method each average to 12ms.
Pinging github.com (as a lower bound) shows an average delay of 20-30ms with a few minutes between each run.

jep-dev commented Oct 29, 2017

In my case, this didn't noticeably improve the delay. It has all the same symptoms (no delay outside of Git repo; delay for anything that causes a new prompt to draw, like hitting enter on an empty line, <ctrl+l>, etc.; no delay pressing other keys or while a command is still running.) This does not appear to be related to my network speed. I could post my versions, config files, etc. but I'd like to look find more general alternative approaches first.

For what it's worth, I'm using bhilburn/powerlevel9k with submodule checking disabled, effectively --ignore-submodules=dirty (not that the project I'm testing on has submodules anyway - more complicated projects I've cloned take much longer.)

Would it be possible to set a flag or add a sentinel file somewhere to indicate if/when the local status has actually changed? Maybe caching the command's output and using the cached version if the (parent) directory's modified date is within some threshold of the cache, or if the cache is similarly recent compared to the current time? The worst effects if it malfunctions should be saving the output every time (negligible contribution to original delay) or showing an outdated status, and both should be fixed by re-tuning the threshold, and of course excluding the cache file via .gitignore.

A few benchmarks for reference...
I can't seem to use the time command on git_prompt_info, but 500 iterations of the command (piped to /dev/null; book-ended by date) averaged to 26ms each.
Timing git add -An and git status with the same method each average to 12ms.
Pinging github.com (as a lower bound) shows an average delay of 20-30ms with a few minutes between each run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment