janabeck/Annotald — Issue #7: Annotald, why so slow?
Author: aecay
Created: 2011-11-16 06:13:09+00:00
State: open
Labels: shortcoming

Annotald can be slowish on large files. There seems to be a root cause, which I have tried some tricks to ameliorate. Namely, the undo system entails caching away a copy of the page's html for each undo step. The undo system is also implicated in the code that checks the result of moving nodes to make sure that the text hasn't changed.

Here are approaches to dealing with the problem:
- (done) Limit undo history to 15 undos (arbitrarily chosen by me). This is not merged in v11.11 (but will be in v11.12). This cuts down on the gargantuan memory usage that was plaguing me for a while (personal best: 800MB of RAM for the Annotald tab!).
- (done, modulo bugs) Limit the scope of the text checking. Instead of checking the whole page text for changes, climb up to the nearest containing ipnode and check. This seems to speed things up a little (caveat: I haven't profiled). It also has introduced subtle bugs, most but not all of which are fixed in v11.11 (all that I know of are fixed on master).
- (not done, tough to do) Revamp the undo handling. Currently, moveNode and friends rely on being able to undo a bad move, so we can't just "turn off" undo to trade safety for speed. Other jQuery-based programs keep a list of functions that transform the DOM, so that undo pops a fn off the stack and calls it. This should be less memory-intensive, and probably faster. But it will take a lot of futzing to get it to work right.