Open dsummersl opened 9 years ago
I did some performance testing of of the tree rendering code - it isn't the limiting factor. Turning off g:undo_inline_undo
by default is the best I think we can do here.
I'm noticing that it's most slow on the first startup, as mentioned here:
https://github.com/simnalamburt/vim-mundo/issues/69#issuecomment-514671319
I'm also noticing that, when I open Mundo for the first time, the last node's diff is rendered before jumping to the top, then it renders again - please pay attention to the start of this video and notice how the diff changes twice.
https://gfycat.com/actualtornindianhare
I'm not sure how impactful this useless initial render is for performance, but it should be noted it'll highlight the whole preview buffer for the "Original' node in diff mode, so that could definitely hurt a bit as well.
As also noted by the aforementioned comment, the next runs of Mundo for that buffer will be significantly faster. That's because the "graphlog" tree doesn't have to be regenerated due to nodesData.is_outdated
evaluating to false.
As for the reason it's slow, according to my findings so far, it's because the code is eagerly computing all the diffs upfront.
For each node in the graph...
Compute the diff for it
Ideally it should only compute the diffs
MundoNextMatch
you iterate forward and compute only the next immediate diff if it isn't in the cache already, until you hit a match).@dsummersl mind reopening this issue?
I've reopened this issue as @resolritter suggested. I think I know what the cause is, but I haven't had time to fix it yet. I'll try to make some spare time.
Hi, is there a workaround for this in the meantime?
@resolritter I happened to be wandering reddit and saw this message https://www.reddit.com/r/neovim/comments/qk7uk1/telescope_pluginextension_that_lets_you_visit/ where-in someone mentioned this issue (although I added the features of this fork lo many years ago I don't use this plugin much anymore). Thanks for your sleuthing! I tried out your recommended and it seems to work great.
@simnalamburt maybe you could give this a shot and see how it works for you on files with large undos? I see a noticeable improvement.
When the gundo window is first opened it paints the entire undo history to the window, which can be slow for large undo histories. Render only what is visible to speed this up. We're doing the same thing now for the
g:gundo_inline_undo
feature, is its a bit slow. Do the same thing for the tree itself.