Huge slowdown of whole Atom UI

[w-barath]

TL;DR: accumulated undo history is causes huge UI slowdowns in Atom.

I had been editing the same 2K-line source file for about a year and over the last few months Atom was becoming more and more unusable. I tried disabling all modules, literally all modules except the ones which allow editing the settings and, and the tree-view, and Atom remained unusable.

The symptoms: Any interaction with the Atom UI, from typing a single character to clicking an input, tab, file in the tree-view, all of these would be followed by a 6-second lockup. However after that lockup I could type without issue until I paused for more than 1 second. Then another 6-second lockup would begin.

This would happen regardless of whether the 2K-line source file was visible, or even in the current window, but would only happen when the 2K-line file was open.

I tried using the profiler to discover the culprit and it revealed that "put" was being called by dbPromise for the vast majority of the CPU time used, but the call graph didn't show the parent of all this activity, which was pretty disappointing and I should probably file a bug against the profiler.

On a lark, I tried copying the 2K file via copy/paste to a new file and closing the original. All the responsiveness issues went away. I deleted the old file and renamed the new file to the old name... and un-freaking-believably the responsiveness issues came back next time I started Atom.

At this point I began to suspect the persistent undo because really that was the only thing which differentiated the file from it's well-performing copy-paste sibling. I openend the Persistent Undo package, saw the blurb about storing in ~/.atom, went there, closed Atom, and deleted the undo history for the 2K-line file. When I started Atom again, no responsiveness issues.

Now the sad part is that I know clicking in the tree view, switching tabs, typing characters in the package search, etc, should have less than nothing to do with the undo history being stored to disk by this package. The real bug must be some underlying mechanism of the undo handler for the entire Atom platform and it's nothing to do with Ben's wonderful persisten undo package. But I have to start somewhere and I can't see how I can start reporting this bug anywhere other than here... hopefully Ben has some insight as to how/why this would occur, or maybe Ben can extend his code to prevent the extensive history from being accessed other than when the file is actively being edited so at least the rest of the UI isn't affected...

[w-barath]

Having looked over the minimal and elegantly simple coffeescript which implements this package, I can't see how anything can be done about it. All it's doing is saving gzipped serialized history to disk and pulling it back via the onWillSave event... I doubt the platform is invoking that event 1s after every keypress... or I hope not lol.

[benwbooth]

The only thing I can think of is only keeping the last 1,000 history events and purging anything older. How much history to keep could be made configurable, of course. I'm not sure when I'll be able to get around to implementing this. Pull requests welcome :)