Any edit (like inserting text) is extremely slow with undotree window open

[rparenzs]

If I insert a small string, say 'aa', into a file, vim itself bogs down and will not allow another edit until the undotree (ut) window updates with the new state.

Now this is probably just a system-specific thing, as I am running on an old 32-bit system, and the slowness seems related to the size of the undo tree (I have set undolevels=2000). If the undo tree is almost empty, there is very little delay. I was just wondering if it could be easily sped up. If the ut window is closed, the edit is instant. If it is open, I guess all 2000 states have to move down a line, but is that what is taking all the time, or is it processing every state for some other reason as well? I really don't how it works. Thanks for listening.

[mbbill]

Yes, it is related to the size of the undo tree. In fact the slowness is caused by rendering the undo tree, i.e. turning the vim's internal undo history format into an ascii tree-like representation. It's done purely in CPU, and since the plug-in was written back in the day when there was no such thing as async script, it will freeze the UI if the tree is big enough.

A simple workaround is to only open undotree window when needed. The undotree window will be updated whenever undo history gets changed, and that happens very often.

I think there might be a way to somehow cache the tree and refresh only when needed. Maybe later on I can take a look

[rparenzs]

Ah, I was thinking of the simplest case where only a new leaf need be drawn at the very top of the tree, no "processing" needed, but since the change could happen in any random part of the tree, I guess you pretty much have to redo/redraw the whole tree from scratch. Thanks. I use this plugin so much, I often want to leave it open, but I'll take your suggestion about only opening it as needed for the big files.