Intense slowdowns on chrome when browser has been open for a while

[Bonkles]

One of our internal users has reported some hefty slowdowns after Chrome has been running for a while. The problem seems to be exacerbated the longer that the browser tab has been open. Need to investigate possible memory leak/etc.

Example changeset area/vicinity, in case that matters:
https://osmcha.org/changesets/94752644

[Bonkles]

Spent the afternoon mapping and have discovered one potential slowdown- as the change history graph gets longer, we seem to be spending an inordinate amount of time (1500 milliseconds) writing the history (which involves some json serialization).

Not saying for sure that this is what's causing THIS particular bug, but as usage of RapiD continues, the history is enlarged, and after a while the history graph can get pretty busy and cause RapiD to start noticeably slowing down after each individual change to the map.

[Bonkles]

Some unanswered questions I have:

1. Did the user observe these slowdowns without having made many changes/edits to the graph? i.e. the RapiD window just sat dormant for a while, and then tried to make a single edit, finding that it was already performing poorly?

2. Perhaps our users can take a performance trace and send the information along?

3. Repro the issue with an incognito browser?

[k-yle]

Hi @Bonkles, we're using a fork of RapiD for the LINZ Address Import in New Zealand (code here and here).

I've noticed a significant slowdown when you add >500 AI features (in our case they all come via the esri data system)

Editing >500 features in iD is nowhere near as slow as adding >500 AI features in RapiD.

Happy to send performance/profiling data if you let me know what you need.

[mapkiwi]

Just adding to say I'm experiencing this issue in Chrome as well, while adding LINZ Buildings (Esri layer) in New Zealand - there is a really noticeable lag when adding new features past the 500 mark.

My temporary workaround is to force refresh the page, but it isn't ideal as I have to re-browse and turn on the layer I was using.

[Bonkles]

@k-yle and @mapkiwi - If you could just point me at an instance of your fork I can try to take a look at some live data. Basically, anything you can send me for repro steps would be helpful. No need for traces quite yet until I get a better handle on the problem.

[mapkiwi]

Hi @Bonkles, in my case, I am just using the regular RapiD editor - with the New Zealand Buildings dataset added and the Facebook/Microsoft default layers turned off. I also use the power user parameter (&poweruser=true) to add larger numbers of features per set, though the slowdown issue seems to happen whether or not I use this.

[vanreece]

So after some investigation it turns out a few things are happening here, first of all there's a large JSON serialization of all the history to write it out to local storage, so that you have history if you refresh the page. When you pass around 200 items, things are officially getting pretty slow in terms of JSON serialization, and it turns out that's also around the time that the local storage started failing to write on my machine because it was too big. So you loose the benefit of even having that serialization. The serialization increases linearly, and around 500 items is when you hit ~1s for the save, which feels very slow in the UI.

@mapkiwi I'm curious how force refreshing the page helps you out, because when I do that and restore my previous session I only have about 200 out of my 500 additions, which I imagine is a pretty big setback for you.

In general, RapiD is ideally suited to have fewer than 100 changes added per changeset, and things can get broken/slow when you go much higher than that. Do you mind my asking why you want to do 500+ items in a changeset? I'd like to understand your usecase better.

[mapkiwi]

I should clarify that this slowdown happens cumulatively independently of whether I have submitted my changesets or not during my session, e.g. where I submit several separate changesets per session, of 50 features or one changeset of 500. So I don't lose any progress (it doesn't prevent me from saving my changesets) - but the speed of the interface when adding/drawing in new features eventually grinds to a halt unless I do a force refresh or start a new tab.

In terms of large changesets, I'm often adding large quantities of LINZ New Zealand Building outlines (an AI-generated dataset available from the ArcGIS dataset gallery) - it's generally faster to make progress adding large areas of building features from this layer with fewer changesets.