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

magit commands are slow #36

Closed
goweol opened this issue Nov 5, 2015 · 17 comments
Closed

magit commands are slow #36

goweol opened this issue Nov 5, 2015 · 17 comments

Comments

@goweol
Copy link

goweol commented Nov 5, 2015

: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.

$ mkdir test; cd test; git init
$ echo 1 > 1; git add 1; git commit -m test
$ echo 1 >> 1
$ gvim

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.

$ git status -sb
## master
M 1

$ time git diff --stat
1 | 1 +
1 file changed, 1 insertion(+)

real 0m0.043s
user 0m0.004s
sys 0m0.028s

vim and git version:

$ LANG= vim --version | head -2
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 14 2015 16:22:00)
Included patches: 1-898

$ git version
git version 2.6.2.280.g74301d6

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.

@goweol
Copy link
Author

goweol commented Nov 5, 2015

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'.
Does it mean ''? Then, refresh is fine on next branch without filetype change.
If not, please describe more detail.

Anyway, I tested dev/test_filetype branch. 'set ft=txt' and . No difference.

@jreybert
Copy link
Owner

jreybert commented Nov 5, 2015

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:

:Time call magit#update_buffer()

with filetype=magit and filetype=txt

@goweol
Copy link
Author

goweol commented Nov 5, 2015 via email

@jreybert
Copy link
Owner

jreybert commented Nov 5, 2015

Well,

I am trying to reproduce your environment. I tried with gvim 7.4.898 and git 2.6.2.280.g74301d6.

:Time call magit#buffer_update()

returns in 0.2 seconds...

However, I am facing a weird behavior that I did not see before.

Staging the file is OK:

0.266 seconds to run :call magit#stage_file()

But unstaging can be very very slow:

12.971 seconds to run :call magit#stage_file()

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!

@jreybert
Copy link
Owner

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?

  • start vim
  • :call magit#utils#start_profile("/tmp/vimagit.log")
  • :call magit#show_magit('v')
  • :call magit#update_buffer()
  • exit vim

thanks

@goweol
Copy link
Author

goweol commented Nov 13, 2015

It seems system() is too slow.

vimagit.log.txt

Now, I compare timing between console and GUI version.

$ vim
:Magit
:Time call magit#update_buffer()
0.602 seconds to run :call magit#update_buffer()
:gui
:Time call magit#update_buffer()
0.809 seconds to run :call magit#update_buffer()

@jreybert
Copy link
Owner

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.

@goweol
Copy link
Author

goweol commented Nov 13, 2015

I believe I ran it in my simple repo.

I think timing changes may caused by host and guest status.
Because there are so many background processes (windows host and linux guest), I cannot run test at same circumstances.
Or it may related to my VIM settings change.
Or VIM itself changes. I updated latest and build with HUGE option for profiling.
Previous version was build with 'BIG' feature option (No profile).

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.
So that, I re-generate vimagit log in the simple repo.

$ LANG= ls -ila
total 16
922057 drwxr-xr-x 3 jason jason 4096 Nov 13 13:41 ./
788189 drwxr-xr-x 14 jason jason 4096 Nov 13 18:51 ../
922058 drwxr-xr-x 8 jason jason 4096 Nov 13 18:51 .git/
922081 -rw-r--r-- 1 jason jason 4 Nov 11 14:54 1

As you can see, there's only ONE file '1'.
And the vimagit.log is:
vimagit.log-2.txt

@fpnick
Copy link

fpnick commented Feb 2, 2016

#65 came up with a similar issue, so just let me add some more information here:
First let me say that everything I'm talking about refers to Linux.
I don't have any problems when working on smaller repos. Only with our big one which I cannot share unfortunately. I could give you the number of files / lines of code under version control though, if that helps narrowing down the issue.

@jreybert
Copy link
Owner

jreybert commented Feb 2, 2016

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.

@fpnick
Copy link

fpnick commented Feb 4, 2016

git status from bash: 4sec
Opening Magit in Vim: 21sec
Refreshing Magit buffer: 11sec

Magit times are with default settings.

@jreybert
Copy link
Owner

jreybert commented Feb 4, 2016

Thanks for the input. Could you give me the same numbers when setting:

let g:magit_default_show_all_files=0

@fpnick
Copy link

fpnick commented Feb 4, 2016

Sure:

Opening Magit in Vim: 11sec
Refreshing Magit Buffer: 10sec

@jreybert
Copy link
Owner

@fpnick @goweol is vimagit still slow with last releases? I did not investigate a lot since february. Now that vimagit is stabilised, I would like to resolve this issue.

@goweol
Copy link
Author

goweol commented Apr 18, 2016

I happily used magit (from Nov 13 2015).
It is slower than command line, but it is acceptable (normally 1~2secs).
Without magit, I have to spend more time to achieve same job with command line and other tool.
So that, I'm fine for closing this issue.
Many thanks!

@fpnick
Copy link

fpnick commented Apr 20, 2016

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 :)

@jreybert
Copy link
Owner

OK, thanks. If you encounter any new slowdown issue, please reopen this ticket.

jreybert added a commit that referenced this issue Oct 12, 2018
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants