Open peplin opened 10 years ago
This also happens to me bringing the CPU usage up to 100%
Sorry for not chiming in earlier here. It seems strange to me that performance would degrade so horribly for both of you while I and other users are not bothered at all. Especially the 100% CPU usage, I definitely would have noticed that the same day :-). Unless there's something different about our environments that brings out the pathological case.
@peplin: Just curious, how reliable is your git bisect
method? I understand the bisect operation to require an automated test that verifies expected to be present/absent behavior, correct? How would you test that with regards to this issue?
You mention that the performance degradation is during scrolling / navigating the cursor. But the changes in the commit identified by the bisect are only executed 1) once when you start editing a note and 2) every time you run the :RelatedNotes
command. So I don't see how this can be related?
I understand the bisect operation to require an automated test that verifies expected to be present/absent behavior, correct? How would you test that with regards to this issue?
An automated test can help, but you can also just test manually. My test was to just open up a note, scroll around, and see if the CPU usage spiked. On the commit right before 677a27f (which is a merge, 3246ed6) if I open a note and scroll around, the one core of my CPU spikes at at most 5% (I'm watching top
in another window). If I check out the next commit, 677a27f, and do the same thing, it jumps to 35% CPU.
I just happened to be setting up a new computer and tried running vim-notes from the head - the issue is still there. After commit 677a27f navigating around gets very laggy and the CPU usage is high. The commit right bofore that, 3246ed6 runs perfectly.
Just wanted to chime in with a "same here". Editing performance is very sluggish with vim-notes on all my computers. CPU usage of Vim jumps up to 100% simply by navigating with jkhl.
Would be interesting to disable all vim-notes features to see if the problem still exists. If it doesn't, then enable one feature at a time to try to identify the particular feature causing the slowdown. Unfortunately I don't have time to do so currently, but will try it once I get some spare time.
Nothing to add here except me too, at 272 notes. Seems to happen with larger, more structured notes.
I am seeing very high CPU usage and sluggish Vim performance when editing any of my notes lately, particularly when scrolling up and down a bulleted list. Interestingly, if I run
set filetype=markdown
in the same instance of Vim, it immediately becomes much faster with no noticeable CPU usage.I ran
git bisect
to see where it went wrong, and found it got slow at commit 677a27fecc4aef6: