-
Notifications
You must be signed in to change notification settings - Fork 49
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
magit commands are slow #36
Comments
You wrote on vim mailing list: could you try this branch of vimagit: https://github.com/jreybert/vimagit/tree/dev/test_filetype Open magit in your simple repository, it should be slow as before. Then, from the magit buffer, type; :set ft=txt and try to refresh. Is it still slow? I don't understand 'try to refresh'. Anyway, I tested dev/test_filetype branch. 'set ft=txt' and . No difference. |
goweol, thanks for your extansive bug report. Yes, 2 seconds is far too slow for a simple repository in one single diff! Thanks for your proposal to help me with this speed issue. When I ask you to refresh the vimagit buffer, I mean press R in the buffer. But further investigation, could I ask you to install the Tim Pope plugin vim-scriptease, and call the following command from the vimagit buffer:
with filetype=magit and filetype=txt |
On the dev/test_filetype branch:
With ft=magit:
1.095 seconds to run :call magit#update_buffer()
With ft=txt:
1.054 seconds to run :call magit#update_buffer()
On the next branch:
With ft=magit:
1.058 seconds to run :call magit#update_buffer()
With ft=txt:
1.068 seconds to run :call magit#update_buffer()
I ran 3 times for each setting and take lowest value.
|
Well, I am trying to reproduce your environment. I tried with gvim 7.4.898 and git 2.6.2.280.g74301d6.
returns in 0.2 seconds... However, I am facing a weird behavior that I did not see before. Staging the file is OK:
But unstaging can be very very slow:
I don't know if it is related to your problem, but this is a first lead to me. Yummy, let's go in vimscript profiling! |
Hmm, my system was just crazy. Two days later, I was not able to reproduce this behavior on my system... Anyway, I am still concerned about your performance issue. Could you please get the next branch, and perform a profiling of vimagit execution for me?
thanks |
It seems system() is too slow. Now, I compare timing between console and GUI version. $ vim |
Hi, in #36 (comment), magit#update_buffer ran in 1 second. Now, I can see it runs in 0.6 seconds? Do you run it with the same repository? Could you run magit#update_buffer with your simple repository example, as in #36 (comment) please? In your traces, I can see that there is one submodule in your repository. You did not mention it in your previous comments. |
I believe I ran it in my simple repo. I think timing changes may caused by host and guest status. BTW, I think system() took most of time. So that, magit itself is not slow. No? And I don't know why you think there is one submodule. $ LANG= ls -ila As you can see, there's only ONE file '1'. |
#65 came up with a similar issue, so just let me add some more information here: |
Well, the first interesting point is the ratio between the time taken by git status command in bash and the magit buffer refresh. For the moment, vimagit is really dumb and perform all the lookup at every refresh. I have some ideas to improve that, keeping a sort of cache, but it is tricky, and may lead to some horrible corner cases. Actually, such hard work is not my priority, I prefer to add some interesting missing features. Anyway, the case of @goweol is still interesting, because on a small repo. But as long as I can't reproduce it, it is difficult to fix. |
git status from bash: 4sec Magit times are with default settings. |
Thanks for the input. Could you give me the same numbers when setting:
|
Sure: Opening Magit in Vim: 11sec |
I happily used magit (from Nov 13 2015). |
I can't give you exact numbers, but like @goweol I'm mostly using vimagit rather than going back to the command line, so it must be acceptable I'd say :) |
OK, thanks. If you encounter any new slowdown issue, please reopen this ticket. |
On first refresh, vimagit can be stuck during several seconds. foldmethod=syntax seems to be the culprit. Longer explanation: Remove folding while we are updating the buffer. writing to the buffer while the folding is enabled can be veryyyyy slow. One last strange thing is that, the first time the buffer is written, it is not slow at all. It is slow the second time, at first refresh (can be order of seconds). Then at third time (2nd refresh), it is fast again.
:Magit or commands in magit buffer took some time.
master branch took about 5 seconds and next branch took about 3 seconds on my real project repo (89MiB of git objects).
So that, I made a simple repo and test vimagit's 'next' branch.
and I run ':Magit' and typing some hotkeys like S or CR.
All the commands took about 2 seconds.
From the command line, git is fast.
vim and git version:
Most of time, I use GVIM (GTK2).
Because my PC environment is slow (antivirus, virtualbox), I'm now satisfied with the next branch.
But If you think '2 seconds' is yet slow (compare to command line speed), I will investigate if you guide me.
I have no objection if you close this issue without further action.
The text was updated successfully, but these errors were encountered: