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

Slow to update, poor benchmark results #358

Closed
leigh-ols opened this issue Sep 6, 2019 · 4 comments
Closed

Slow to update, poor benchmark results #358

leigh-ols opened this issue Sep 6, 2019 · 4 comments

Comments

@leigh-ols
Copy link

Recently Command-T has been slow to update. A vim profile revealed it was actually matchit.vim (for whatever reason). I disabled that and the issue improved dramatically but it is still slow.

I ran a benchmark and these are my results.

Rehearsal -----------------------------------------------------
pathological        5.710000   0.020000   5.730000 (  5.737230)
command-t           3.060000   0.000000   3.060000 (  3.068981)
chromium (subset)   3.420000   0.180000   3.600000 (  2.245106)
chromium (whole)   10.380000   0.040000  10.420000 (  2.852794)
big (400k)         15.570000   0.050000  15.620000 (  4.173315)
------------------------------------------- total: 38.430000sec

                        user     system      total        real
pathological        5.850000   0.010000   5.860000 (  5.867898)
command-t           2.750000   0.000000   2.750000 (  2.752038)
chromium (subset)   3.420000   0.190000   3.610000 (  2.293511)
chromium (whole)   10.600000   0.070000  10.670000 (  3.032051)
big (400k)         15.330000   0.050000  15.380000 (  4.214814)
Rehearsal -----------------------------------------------------

This is on a i7 4790k with 16GB ram, in an ubuntu 16.04 virtual machine (VirtualBox) with 4 cpu's and 8GB Ram.

One might think this was something to do with the virtual machine. But this has never been an issue in the past and nothing has really changed. I can only imagine I must be an edge case as this kind of performance drop wouldn't go unnoticed.

Have there been any significant changes to the code base that may have caused this?

@leigh-ols
Copy link
Author

leigh-ols commented Sep 6, 2019

Update:

A little more research shows that I get similar (very slightly better) benchmark results on a similar setup at home but with more ram and a 4690k.

I've re-compiled all the way back to 5.0 and the benchmark results still remain similar.

Playing around within Vim, Command-T is actually very fast and usable for a while but begins to slow significantly over time. I've yet to figure out what causes this slow down. Opening 100 buffers in succession does cause a slowdown in Vim itself and Command-T but not to anywhere near the same extent as I'm witnessing after having Vim open for a day or two of constant use.

Here is a profile log extract to show exactly how bad the issue can become after a couple of days usage:

FUNCTIONS SORTED ON SELF TIME
count  total (s)   self (s)  function
   29             10.813844  commandt#private#HandleKey()
   18              5.563804  commandt#private#Backspace()
    2   3.669891   1.299891  commandt#private#Cancel()
    1   1.413662   1.110772  commandt#BufferFinder()
    1   1.357917   1.056674  commandt#FileFinder()
    6              1.003313  UltiSnips#SnippetsInCurrentScope()

That's 10 seconds to handle 29 keypresses.

Here is a profile on the same project after a fresh vim start:

FUNCTIONS SORTED ON SELF TIME
count  total (s)   self (s)  function
   28              4.015040  commandt#private#HandleKey()
    4              0.604396  UltiSnips#SnippetsInCurrentScope()
    1   0.675788   0.430798  commandt#FileFinder()
    2              0.281444  commandt#private#ToggleFocus()
    1   1.077175   0.263648  commandt#private#AcceptSelection()
    1              0.167863  commandt#private#ClearPrevWord()

But the numbers don't really reflect the huge slowdown. It feels like the difference between comfortably usable and unbearably slow.

@wincent
Copy link
Owner

wincent commented Sep 10, 2019

Have there been any significant changes to the code base that may have caused this?

Nope.

My first suspicion is that some expensive autocommand is running and bogging things down. Could you try reproducing with everything except Command-T disabled and a basically empty vimrc?

It's true that your benchmarks are a bit slow, but not dramatically slower. For comparison, here's a typical run on my 2015 MacBook Pro:

                        user     system      total        real
pathological        1.060000   0.010000   1.070000 (  1.134879)
command-t           0.820000   0.010000   0.830000 (  0.824931)
chromium (subset)   3.450000   0.610000   4.060000 (  0.817602)
chromium (whole)    4.900000   0.060000   4.960000 (  0.955989)
big (400k)          6.880000   0.080000   6.960000 (  1.566018)
Rehearsal -----------------------------------------------------
pathological        1.160000   0.030000   1.190000 (  1.315939)
command-t           1.020000   0.010000   1.030000 (  1.089404)
chromium (subset)   3.340000   0.580000   3.920000 (  0.985002)
chromium (whole)    4.570000   0.050000   4.620000 (  0.941458)
big (400k)          6.870000   0.070000   6.940000 (  1.273047)
------------------------------------------- total: 17.700000sec

@leigh-ols
Copy link
Author

Hi,

I've tried this but it is very difficult to reproduce, as the issue only gets really bad after significant amounts of heavy use. And I can't use my vim as I usually would without my standard dev setup/plugins.

I will continue to hunt this down in my spare time and see if I can come up with anything of use.

@wincent
Copy link
Owner

wincent commented Aug 26, 2022

Given the big rewrite for v6.0.x, I'm closing all older issues as there is unlikely to be anything significant happening on the 5-x-devel branch from here on1. Feedback issue for 6.0.x is here:

Footnotes

  1. Patches and PRs would be welcome, but my personal efforts are going to be directed towards main.

@wincent wincent closed this as not planned Won't fix, can't repro, duplicate, stale Aug 26, 2022
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

2 participants