Closed leigh-ols closed 2 years ago
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.
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
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.
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 on[^patches]. Feedback issue for 6.0.x is here:
[^patches]: Patches and PRs would be welcome, but my personal efforts are going to be directed towards main
.
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.
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?