As outlined in #68, when undo chains get quite lengthy (exacerbated by saving undo history), vundo and emacs in general slow down. It's highly sensitive to line length (M-: (current-column) tells you how long your lines are). Once past say 5k-10k columns, slowdown becomes apparent, and at >20k it becomes very noticeable, not just in vundo, but in all buffers while vundo is open. We increased the draw speed by ~10x in da90207, but that only affects how quickly vundo is drawn, not the slow-down from having such long lines around at all.
Here is an idea to mitigate this:
Rather than drawing into the buffer, "draw" into a data store — a ragged list of vectors.
When point moves (via normal vundo navigation), if this necessitates the display of new data in the window, redraw quickly from the data store: quick-draw.
Each vector in the data store list will correspond to one row of the display, and will be tagged with a column offset of its first entry, such that the full set of vectors completely describes what should be drawn at any given column offset.
The vectors contains a compact representation for the drawn item at point, entries like:
Type: blank, node or connector.
If node, the node object itself.
If connector, the connector type: horizontal, vertical, angle, or angle-branch.
"Drawing" to the data store is then straightforward:
use precisely the current draw algorithm, except instead of examining what's in the buffer, examine what's in the data store, extending it as needed.
This may need to use lists while building and be converted to vectors at the end of the draw. If all the list traversal during draw is too slow, using a temporary list of short vectors (e..g. length=512) and adding new ones to it as needed will cut this down.
With the data store fully populated, quick-drawing then just involves:
computing the (notional) column offset of the desired draw's start.
starting with the first vector on the list whose offset is exceeded by the desired final column offset (given the desired draw width), skipping to the appropriate offset within the vector.
translating the entries found there into drawn nodes (indicating saved status, adding the node as a text property, etc., as usual).
continuing to the next row-vector which contains in-range data and drawing those, until all row-vectors have been visited.
We could choose to draw just a window-width's worth of columns (so that moving off window always necessitates a quick-draw), or some larger number of columns (1000?) to minimize redraw; this would need some experimentation.
As outlined in #68, when undo chains get quite lengthy (exacerbated by saving undo history), vundo and emacs in general slow down. It's highly sensitive to line length (
M-: (current-column)tells you how long your lines are). Once past say 5k-10k columns, slowdown becomes apparent, and at >20k it becomes very noticeable, not just in vundo, but in all buffers while vundo is open. We increased the draw speed by ~10x in da90207, but that only affects how quickly vundo is drawn, not the slow-down from having such long lines around at all.Here is an idea to mitigate this: