Redraw / UI slow after about 100 edits performed

[javbw]

I was using Safari (10.10 + latest Safari) , but with the "save" button refusing to work 50% of the time (for a month or so) I switched to Chrome (44.0.2403.89). The chrome browser is more stable for iD and has a more aggressive caching wcheme for the background imagery, but for the last 30 edits, any time the edit count reaches 90-100 edits, the redraw of the movemnet of OSM data and the iD UI get laggier and laggier, and by 110+ edits the lag is so bad that positioning points is impossible.

This was not so much of an issue in Safari - i could get to 300+ edits without this occuring. I assume it is a cache size issue with iD. Maybe it is something i can adjust in settings, but I am not sure and this ptobbaly affects others.

Since iD in Safari is broken, please look into solving this issue with chrome, or give me a suggestion on how to mitigate this redraw/UI lag.

[emmafobang]

same problem with me

[bhousel]

Regarding Safari - it got a little crashy around 9.0.1 (see #2848), but seems to be better these days. I don't know of an issue that was causing saves to fail.

That said, I do want to improve iD's performance once it gets up in the high (100ish) edit count. I've been using Chrome's profiler and fixed a memory leak in f2a8f71. But there is still more we can improve.

The architecture of iD is that as you scroll around, the visible stuff of OSM gets loaded into a base Entity graph, and then as you edit, iD is constantly figuring out the difference between the base graph and the current graph. Clearly, the more edits you make, the slower this process will be.

The bottlenecks seem to be:

• iD.Difference
  Can probably be optimized a bit more, replace lodash with loops and use other tricks for hot code. I want to cache the current Difference somewhere (maybe in iD.History#difference) so that repeated requests don't need to recalculate the difference.
• iD.History#toJSON
  This is the code that saves a user's edit history to localStorage. Same idea as Difference - we probably don't need to do all this work every single time it gets called.
• iD.History edit stack (undo states)
  The edit number is a little misleading. Right now I see:
  
  But I have over 500 edits in the stack. Not all edits increment the number. Realistically I am not going to undo back over 500 edits. We could cap this stack at some number and coalesce earlier edits together into a single entry, which would make everything that iterates over the history stack faster.

cc @jfirebaugh, maybe he has thought about it?

[bhousel]

This is a kind of old issue.. In the course of fixing #4611, I realized that iD.coreDifference was causing a lot of the slowness, so I optimized that code a bit. Now things are significantly faster.