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

Very slow in home folder because of VCS prompt segment #244

Closed
dj-hedgehog opened this Issue Apr 8, 2016 · 23 comments

Comments

Projects
None yet
6 participants
@dj-hedgehog

dj-hedgehog commented Apr 8, 2016

I turned my home-folder ~ into a dotfiles repository with a lot of untracked files.
Ever since I made this change zsh is unusable slow while I'm located in the home-folder. It takes like 5-10 seconds to register keystrokes or execute anything.

Since I like the VCS segment I'd like to know what I can do about it without removing it entirely? Can I disable it in certain folders or is there some git function I can use?

@jguenther

This comment has been minimized.

Show comment
Hide comment
@jguenther

jguenther Apr 8, 2016

What I do is I make a ~/dotfiles repo and have a makefile in there that symlinks ~/.file to ~/dotfiles/file if they don't already exist. e.g. ~/.bashrc is a symlink to ~/dotfiles/bashrc, etc.

jguenther commented Apr 8, 2016

What I do is I make a ~/dotfiles repo and have a makefile in there that symlinks ~/.file to ~/dotfiles/file if they don't already exist. e.g. ~/.bashrc is a symlink to ~/dotfiles/bashrc, etc.

@dritter

This comment has been minimized.

Show comment
Hide comment
@dritter

dritter Apr 8, 2016

Collaborator

@dj-hedgehog Thanks for the report.

The way @jguenther suggests would work. But I don't like it that this theme slows your terminal that much down. So I create a repository with 500.000 untracked files, and voilá it is slow as hell.
For now I can say that it has to do with the checking of untracked files. If I deactivate this (currently only available on the next branch) by setting POWERLEVEL9K_VCS_GIT_HOOKS=(vcs-detect-changes git-aheadbehind git-stash git-remotebranch git-tagname) (notice that I took out git-untracked). This is no real solution, as it deactivates the whole checking of untracked files for all repositories.
I need to investigate this further. Just wanted to inform you about my ongoings.

Collaborator

dritter commented Apr 8, 2016

@dj-hedgehog Thanks for the report.

The way @jguenther suggests would work. But I don't like it that this theme slows your terminal that much down. So I create a repository with 500.000 untracked files, and voilá it is slow as hell.
For now I can say that it has to do with the checking of untracked files. If I deactivate this (currently only available on the next branch) by setting POWERLEVEL9K_VCS_GIT_HOOKS=(vcs-detect-changes git-aheadbehind git-stash git-remotebranch git-tagname) (notice that I took out git-untracked). This is no real solution, as it deactivates the whole checking of untracked files for all repositories.
I need to investigate this further. Just wanted to inform you about my ongoings.

@dritter

This comment has been minimized.

Show comment
Hide comment
@dritter

dritter Apr 9, 2016

Collaborator

Bad news: This is an issue of git itself. My first thought was, to cut off the response of git (with tail -n 1), but git computes the whole list of files before handing over to tail.. Second thought was to add an .gitignore with all untracked files in it (or a *), but git needs to check each file against this mask (which is slow). There seems no way to get just a boolean value out of git to know if there is an untracked file at all.
Even other commands than git status are not fast enough (like git ls-files, as suggested here). @sindresorhus did a benchmark of git commands.

IMHO there are two ways that would work:

  1. as @jguenther suggested, clone your dotfiles repository to another location, and link all relevant files to your home directory.

  2. do the vcs call asynchronously. Like the pure guys did. But that would be a major refactoring of the code.

  3. disable the untracked files checking in your home directory. To do so, you could add piece of code in your .zshrc: This would not work, as your .zshrc does not get re-evaluated every time. You could add a precmd instead.

    if [[ $(print -P "%~") == '~' ]]; then
      POWERLEVEL9K_VCS_GIT_HOOKS=(vcs-detect-changes git-aheadbehind git-stash git-remotebranch git-tagname)
    fi

But apart from that, all we could do is sending a patch to git..
Sorry.

Collaborator

dritter commented Apr 9, 2016

Bad news: This is an issue of git itself. My first thought was, to cut off the response of git (with tail -n 1), but git computes the whole list of files before handing over to tail.. Second thought was to add an .gitignore with all untracked files in it (or a *), but git needs to check each file against this mask (which is slow). There seems no way to get just a boolean value out of git to know if there is an untracked file at all.
Even other commands than git status are not fast enough (like git ls-files, as suggested here). @sindresorhus did a benchmark of git commands.

IMHO there are two ways that would work:

  1. as @jguenther suggested, clone your dotfiles repository to another location, and link all relevant files to your home directory.

  2. do the vcs call asynchronously. Like the pure guys did. But that would be a major refactoring of the code.

  3. disable the untracked files checking in your home directory. To do so, you could add piece of code in your .zshrc: This would not work, as your .zshrc does not get re-evaluated every time. You could add a precmd instead.

    if [[ $(print -P "%~") == '~' ]]; then
      POWERLEVEL9K_VCS_GIT_HOOKS=(vcs-detect-changes git-aheadbehind git-stash git-remotebranch git-tagname)
    fi

But apart from that, all we could do is sending a patch to git..
Sorry.

@bhilburn

This comment has been minimized.

Show comment
Hide comment
@bhilburn

bhilburn Apr 11, 2016

Owner

@dritter - What are your thoughts on moving the dirty check into a precmd? It seems like that might speed up the responsiveness of the re-draw, if I'm understanding how it works correctly?

Owner

bhilburn commented Apr 11, 2016

@dritter - What are your thoughts on moving the dirty check into a precmd? It seems like that might speed up the responsiveness of the re-draw, if I'm understanding how it works correctly?

@dritter

This comment has been minimized.

Show comment
Hide comment
@dritter

dritter Apr 12, 2016

Collaborator

Hmm. The only way how I imagine these precmds are executed are:

  1. right before the prompt is printed. Then it will make no difference to executing this function as vcs_info-hook
  2. less often. This would make a difference, but will give us not enough information (the underlying repo might have changed in the meantime).

I think there is no faster way than doing it like we do (except for the async way). Best would be submitting a PR to git, adding a new command that will stop right after a valid (considering the .gitignore) untracked file was found.

Collaborator

dritter commented Apr 12, 2016

Hmm. The only way how I imagine these precmds are executed are:

  1. right before the prompt is printed. Then it will make no difference to executing this function as vcs_info-hook
  2. less often. This would make a difference, but will give us not enough information (the underlying repo might have changed in the meantime).

I think there is no faster way than doing it like we do (except for the async way). Best would be submitting a PR to git, adding a new command that will stop right after a valid (considering the .gitignore) untracked file was found.

@bhilburn

This comment has been minimized.

Show comment
Hide comment
@bhilburn

bhilburn Apr 12, 2016

Owner

@dritter - Thanks for the thoughts!

Hm... maybe I'll look into what it would take to do that check asynchronously, as the project did in your link. That would be pretty cool, but it sounds like the workload might be... heavy.

Owner

bhilburn commented Apr 12, 2016

@dritter - Thanks for the thoughts!

Hm... maybe I'll look into what it would take to do that check asynchronously, as the project did in your link. That would be pretty cool, but it sounds like the workload might be... heavy.

@chenjuntong

This comment has been minimized.

Show comment
Hide comment
@chenjuntong

chenjuntong May 1, 2016

@dritter
On my computer it seems that both "symlinks" and "modify.zshrc" ways don't work at all.

chenjuntong commented May 1, 2016

@dritter
On my computer it seems that both "symlinks" and "modify.zshrc" ways don't work at all.

@dritter

This comment has been minimized.

Show comment
Hide comment
@dritter

dritter May 2, 2016

Collaborator

@chenjuntong This is strange. Do you have a huge repository as well? Or does this happen in any repository (even small ones)?
And do you operate on a network-mounted folder?

Collaborator

dritter commented May 2, 2016

@chenjuntong This is strange. Do you have a huge repository as well? Or does this happen in any repository (even small ones)?
And do you operate on a network-mounted folder?

@chenjuntong

This comment has been minimized.

Show comment
Hide comment
@chenjuntong

chenjuntong May 4, 2016

@dritter This happen in any repository.When using powerlevel9k, the entire zsh seems slow down. Even simple command like "cd" is slower too. Extremely slow when using vcs. Therefore whether I operate on local folders(which I operate on) or network-mounted folders it is the same.

chenjuntong commented May 4, 2016

@dritter This happen in any repository.When using powerlevel9k, the entire zsh seems slow down. Even simple command like "cd" is slower too. Extremely slow when using vcs. Therefore whether I operate on local folders(which I operate on) or network-mounted folders it is the same.

@dritter

This comment has been minimized.

Show comment
Hide comment
@dritter

dritter May 4, 2016

Collaborator

@chenjuntong That is strange. The vcs segment uses ZSHs VCS_INFO which does massively disk operations. So the vcs segment should be significantly faster on local folders than on network mounts..

Are your repositories git or mercurial ones? (Git should be faster than mercurial).

And how fast is the invocation of time git status or time hg st in your repo (with disabled vcs of course)? If the pure command is slow, this is something we cannot do anything about..

Collaborator

dritter commented May 4, 2016

@chenjuntong That is strange. The vcs segment uses ZSHs VCS_INFO which does massively disk operations. So the vcs segment should be significantly faster on local folders than on network mounts..

Are your repositories git or mercurial ones? (Git should be faster than mercurial).

And how fast is the invocation of time git status or time hg st in your repo (with disabled vcs of course)? If the pure command is slow, this is something we cannot do anything about..

@chenjuntong

This comment has been minimized.

Show comment
Hide comment
@chenjuntong

chenjuntong May 5, 2016

@dritter My repositories are git ones.
Here is the time git status.Seems fast.

**When I disable vcs,every command becomes fast as usual.**Therefore I guess the problem is on vcs.
Thanks for your patience.

chenjuntong commented May 5, 2016

@dritter My repositories are git ones.
Here is the time git status.Seems fast.

**When I disable vcs,every command becomes fast as usual.**Therefore I guess the problem is on vcs.
Thanks for your patience.

@bhilburn

This comment has been minimized.

Show comment
Hide comment
@bhilburn

bhilburn May 14, 2016

Owner

Yeah, there seem to be some speed issues with ZSH's VCS_INFO submodule. As @dritter said before, the only way we might be able to get around this is to force some things to run asynchronously to the prompt draw. I haven't had a chance to look into this, yet, but would like to.

If anyone else is interested in contributing on this front, I consider this to be an important effort.

Owner

bhilburn commented May 14, 2016

Yeah, there seem to be some speed issues with ZSH's VCS_INFO submodule. As @dritter said before, the only way we might be able to get around this is to force some things to run asynchronously to the prompt draw. I haven't had a chance to look into this, yet, but would like to.

If anyone else is interested in contributing on this front, I consider this to be an important effort.

@ayyjayess

This comment has been minimized.

Show comment
Hide comment
@ayyjayess

ayyjayess May 15, 2016

Contributor

I've made the RPROMPT async based on this blog post. You can see the changes at master...andjscott:master if interested.

asciicast

Contributor

ayyjayess commented May 15, 2016

I've made the RPROMPT async based on this blog post. You can see the changes at master...andjscott:master if interested.

asciicast

@chenjuntong

This comment has been minimized.

Show comment
Hide comment
@chenjuntong

chenjuntong May 16, 2016

@andjscott I am sorry that this solution hasn't completely solve the problem. It maybe a little faster than the original config. Still, every command slower when using the VCS_INFO.

chenjuntong commented May 16, 2016

@andjscott I am sorry that this solution hasn't completely solve the problem. It maybe a little faster than the original config. Still, every command slower when using the VCS_INFO.

@ayyjayess

This comment has been minimized.

Show comment
Hide comment
@ayyjayess

ayyjayess May 18, 2016

Contributor

powerlevel9k_prepare_prompts gets called twice currently due to the zle-line-init and the precmd hooks. Is there a reason for this? The prompt seems to work fine without the zle-line-init hook.

Contributor

ayyjayess commented May 18, 2016

powerlevel9k_prepare_prompts gets called twice currently due to the zle-line-init and the precmd hooks. Is there a reason for this? The prompt seems to work fine without the zle-line-init hook.

@dritter

This comment has been minimized.

Show comment
Hide comment
@dritter

dritter May 18, 2016

Collaborator

@andjscott Only accidental. :D We had some trouble getting the vi_mode to work. The bug was introduced at this time..

Btw. the async prompt looks awesome! Thank you very much!

Collaborator

dritter commented May 18, 2016

@andjscott Only accidental. :D We had some trouble getting the vi_mode to work. The bug was introduced at this time..

Btw. the async prompt looks awesome! Thank you very much!

@bhilburn

This comment has been minimized.

Show comment
Hide comment
@bhilburn

bhilburn May 27, 2016

Owner

Work continues in #263...

Owner

bhilburn commented May 27, 2016

Work continues in #263...

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 29, 2016

@chenjuntong try brew install git
Had the same issue, my terminal was extremely slow after installing the powerlevel9k theme, and spent hours trying to get it solved until I hit brew install git to override the default git that was shipped with my OSX.
brew install git worked just fine for me.

ghost commented May 29, 2016

@chenjuntong try brew install git
Had the same issue, my terminal was extremely slow after installing the powerlevel9k theme, and spent hours trying to get it solved until I hit brew install git to override the default git that was shipped with my OSX.
brew install git worked just fine for me.

@bhilburn

This comment has been minimized.

Show comment
Hide comment
@bhilburn

bhilburn Jun 14, 2016

Owner

@andela-oadesanya - Wow, really? Do you know what version ships with OSX by default, and what version of git you have now?

Owner

bhilburn commented Jun 14, 2016

@andela-oadesanya - Wow, really? Do you know what version ships with OSX by default, and what version of git you have now?

@dritter

This comment has been minimized.

Show comment
Hide comment
@dritter

dritter Jun 14, 2016

Collaborator

@bhilburn Apple ships git version 2.7.4 (Apple Git-66) on El Capitan (10.11.5).

Collaborator

dritter commented Jun 14, 2016

@bhilburn Apple ships git version 2.7.4 (Apple Git-66) on El Capitan (10.11.5).

@bhilburn

This comment has been minimized.

Show comment
Hide comment
@bhilburn

bhilburn Aug 11, 2016

Owner

Closing this to continue async work in #263 and vcs speedup work in #287.

Owner

bhilburn commented Aug 11, 2016

Closing this to continue async work in #263 and vcs speedup work in #287.

@chenjuntong

This comment has been minimized.

Show comment
Hide comment
@chenjuntong

chenjuntong Aug 18, 2016

@andjscott @andela-oadesanya @bhilburn "removing-zle-functions: https://github.com/bhilburn/powerlevel9k/tree/removing-zle-funcs" has solved this problem. Thank you!

chenjuntong commented Aug 18, 2016

@andjscott @andela-oadesanya @bhilburn "removing-zle-functions: https://github.com/bhilburn/powerlevel9k/tree/removing-zle-funcs" has solved this problem. Thank you!

@bhilburn

This comment has been minimized.

Show comment
Hide comment
@bhilburn

bhilburn Aug 18, 2016

Owner

@chenjuntong - Happy to hear that! We'll get that merged into master soon.

Owner

bhilburn commented Aug 18, 2016

@chenjuntong - Happy to hear that! We'll get that merged into master soon.

@bhilburn bhilburn closed this Aug 18, 2016

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