Skip to content
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

Gstatus performance is slow, especially on Windows #1254

Open
tankorsmash opened this issue Apr 30, 2019 · 10 comments

Comments

Projects
None yet
4 participants
@tankorsmash
Copy link

commented Apr 30, 2019

In addition to git status, it's now making calls to git config --list, git diff, git diff --cached, git log ..@{u}, and git log @{u}... Check the times on those.

Originally posted by @tpope in #1176 (comment)


I've opened a new issue to focus on purely the Windows portion. I went and compared performance on v2.4 (with the old :Gstatus) to master, and the old one performs noticeably better.

I tried all those git config --list etc commands and they're all near-instant, but I believe most of the time is spent on the Windows Explorer opening and closing the cmd windows. I'm not sure what else to provide though.

The only delay every happens when the cmd window is opening and closing, and while it does happen a few times in v2.4, it happens significantly more in master and slows down the workflow. It's not a gamebreaker, but given how smooth it worked before, I'd like to see if it could be improved.

I do have a number of untracked files, but in this gif, I :Gstatus, then hit P on a tracked file, then close it with q without making any changes and then a ton of cmd windows open up: https://i.imgur.com/4rO1qQ0.gif

@tankorsmash tankorsmash changed the title In addition to `git status`, it's now making calls to `git config --list`, `git diff`, `git diff --cached`, `git log ..@{u}`, and `git log @{u}..`. Check the times on those. Gstatus performance slow vs v2.4 Apr 30, 2019

@tpope

This comment has been minimized.

Copy link
Owner

commented Apr 30, 2019

The repeated cmd window thing sounds like a FocusGained loop, which should now be disabled on Windows. You're on the very latest?

@tankorsmash

This comment has been minimized.

Copy link
Author

commented Apr 30, 2019

I just confirmed, 16b7a06 is the commit I'm on, and it was the same as the commit in the gif (given no updates were in the last few days).

I just tried :Gstatus out on a repo with only 7 listings as untracked, and repeated the same P and q on a test file, and it seemed like a comparable amount of time was spent waiting for those windows to open and close.

@tpope tpope changed the title Gstatus performance slow vs v2.4 Gstatus performance slow on Windows May 1, 2019

@tpope

This comment has been minimized.

Copy link
Owner

commented May 1, 2019

Something else is probably causing a loop then. Try disabling the rest of your config to see if it's another plugin or something in your vimrc triggering it.

For general slowness, see my comment here.

@tankorsmash

This comment has been minimized.

Copy link
Author

commented May 1, 2019

Without any plugins beyond colorscheme, vimplug and fugitive on master, the performance is consistent with all of them enabled: https://i.imgur.com/RuIR8hL.gif

It's a bummer I can't give you more information. I'll just stick with v2.4 and maybe I can figure out something that causes that loop. Thanks!

@tpope

This comment has been minimized.

Copy link
Owner

commented May 1, 2019

You can try commenting out the autocommands inside the autoload file and see if that fixes it.

@tpope

This comment has been minimized.

Copy link
Owner

commented May 1, 2019

Actually that GIF looks like about 10 commands, which, with Fugitive needing 5 per :Gstatus load, sounds like it's being reloaded twice. Debugging autocommands can probably get it down to 5. My linked comment talks about getting it down further.

@asknet

This comment has been minimized.

Copy link

commented May 12, 2019

I have same issue as well

@amadeus

This comment has been minimized.

Copy link

commented May 20, 2019

I'm on macOS in a somewhat sizeable repo and updating Gstatus can take up to 2 seconds to render properly. I don't mind that latency - except it's a bit annoying that it happens on focus. Would be nice if I could perhaps disable those focus/bufdelete/shelcmdpost autocommands completely, and just rely on manual updating with R or invoking Gstatus manually.

Although I will say - git status is super quick in terminal or via :!git status, so maybe there's more room for improvement?

@tpope

This comment has been minimized.

Copy link
Owner

commented May 21, 2019

Quoting myself from #637 for posterity:

Batching commands sounds really hard, but please by all means investigate. I would accept a solution that batches only on Windows, if that makes things any easier.

For a quick win, the two calls to diff could each be skipped if the relevant section of git status is empty. And the two calls to log could be cached based on the timestamps of the two refs being compared.

@amadeus running 5 commands (or 10 if there's a double reload bug) will certainly be slower than a single git status invocation, though 2 seconds sounds high. Use scriptease.vim to :Time call system('git status') and see how much that accounts for. Possibly your shell is adding a lot of overhead.

@tpope tpope changed the title Gstatus performance slow on Windows Gstatus performance is slow, especially on Windows May 21, 2019

@tpope

This comment has been minimized.

Copy link
Owner

commented May 22, 2019

Almost forgot to mention, there is an option for turning autoreload off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.