Bugzilla – Bug 196
History window is slow to populate if Undo stack is large.
Last modified: 2018-08-20 11:45:29 UTC
This bug is split out from discussion on bug 113. Vaughan: > Looked into history window slowness. It was doing unnecessary repetitive > clearing and filling the list, so if it's still slow, then we will have real > evidence that UndoManager is slow at scanning the stack. Gale: When I tried (Comment 5) to import 50 WAVs via OD, History took 10 seconds to load (while the waveforms were still being drawn). That is still true now. But when I now imported 30 MP3s mostly 3 minutes long, accessing History (after the imports had completed of course) took 3 minutes. During most of this time History was empty and not responding. Loading history took 2.5 minutes when repeating the test on a freshly booted machine.
Commit 10583: Calculate space usage for a state frame (UndoStackElem) in UndoManager::PushState, i.e., only when the UndoStackElem is created, rather than for all UndoStackElem's every time we open History Window. This should considerably speed up opening History Window when the stack is large (many frames and/or lots of data), and fix bug 196.
The fix makes a huge difference on Windows - access to history is now near immediate. Also access is immediate now on Mac and Ubuntu (though it seems it wasn't a problem on Mac before the fix). Thanks for this.