iD performance issues since version 2.20.0

[dafadllyn]

iD has become very laggy and resource-hungry since version 2.20.0 (using Firefox, Chrome, Edge and Safari on Mac and Windows).

Unfortunately, iD is not usable anymore on an older computer with a 2.4 GHz Intel Core i5-2435M processor, on which the previous version ran quite smoothly. On a newer computer with a 1.7 GHz Intel Core i5-8350U processor, iD uses about 50% CPU and is laggy but usable during about the first two minutes after launch, but then iD's CPU usage drops to about 10% and it becomes more responsive.

[bryceco]

How much RAM does your computer have, and how much RAM does it report your browser using?

[dafadllyn]

The older machine has 4 GB of RAM (of which 3.0 GB is in use), the newer 16 GB (of which 4.2 GB is in use). The browsers use about 700–800 MB loading this map section in iD.

[bhousel]

The older machine has 4 GB of RAM (of which 3.0 GB is in use), the newer 16 GB (of which 4.2 GB is in use). The browsers use about 700–800 MB loading this map section in iD.

Yes, that's Bern, which is pretty heavily micromapped. The CPU usage is because iD is validating all those features as they stream in from the OSM API.

I'd like to move the validation code from a RenderIdleCallback to a workerpool, so it's not bogging down the main thread so much. This will help a bunch.

For what it's worth, it is catching a ton of real issues:

[dafadllyn]

Doesn't iD just checks my edits? At least that's what the "Issues" settings tab says.

(As for the screenshot, this likely isn't an issue. The buildings in the old town of Bern are very old and thus quite irregular. They have been carefully mapped by a user using a map with the official ground plans we have the right to use.)

[bhousel]

Doesn't iD just checks my edits? At least that's what the "Issues" settings tab says.

It checks everything, however the issues tab can adjust what you're shown. It needs to check everything so that the validator can know the difference between issues that existed before and issues that the user introduced - though from #8613 it sounds like there is a bug in how the changeset tags are counted.

(As for the screenshot, this likely isn't an issue. The buildings in the old town of Bern are very old and thus quite irregular. They have been carefully mapped by a user using a map with the official ground plans we have the right to use.)

The points in that screenshot are 3cm apart. I think most people would consider this an error, however I think it's pretty minor. I sometimes disable the "points too close" warning if I find it's being too noisy.

[sun-geo]

@dafadllyn Thanks for raising this ticket. I notice the same uncomfortable behavoir starting using iDs version v2.20.

I also see a ton (while using v2.20) of validator warnings related to PTV2 bus route relations and was wondering if this is maybe causing the performance issue. Is this validation related to the NSI? Is there any option to disable the NSI checks?

[bhousel]

I also see a ton (while using v2.20) of validator warnings related to PTV2 bus route relations and was wondering if this is maybe causing the performance issue. Is this validation related to the NSI? Is there any option to disable the NSI checks?

I've been looking into this and I think the slowness is because the entire route and all of its members and their parts gets validated. This is usually unnecessary and time consuming, so I think I'm going to adjust it so that each validator function will be responsible for whether or not it wants to recurse down and check the whole relation. (when adjusting the tags on a bus route, we dont have to look at all the nodes of all the ways).

[MarkusGaugg]

I can reproduce that, unfortunately iD has become very slow.

[lgommans]

Can confirm, in Firefox on Linux (with plenty of RAM but a pretty slow 8th gen i5 CPU) it has become very slow since the release. Sometimes I put up with it but it's really borderline unworkable. Every click, no matter if you're editing a line or clicking the + button to add a new tag, takes about a full second to respond.

[Strubbl]

Can confirm, in Firefox on Linux (with plenty of RAM but a pretty slow 8th gen i5 CPU) it has become very slow since the release.

I can confirm this issue with Chromium 92 on Linux with a similar hardware

[Korgi2]

The Same issue is happening to me on Firefox 90.0.2. ID opens and its basically unusable and takes several seconds to respond even on a 32gb machine.

[ZeLonewolf]

64g of ram on Chrome 92.0.4515.131 checking in.

Seems to mostly work fine to me with the exception of very densely mapped areas. The center of Paris on zoom 16 grinds my web browser to a halt: https://www.openstreetmap.org/edit?editor=id#map=16/48.8663/2.3607

[bhousel]

I'm curious whether people have better luck with a version that has the validation improvements? Compare with this: https://mapwith.ai/rapid/59e1bd4-16.x-dist/index.html It shouldn't be over-validating entire routes anymore.

[ZeLonewolf]

@bhousel just tried the same Paris location. It's still very laggy (which I expected, given the huge number of objects), but it doesn't completely lock up.

[bhousel]

@bhousel just tried the same Paris location. It's still very laggy (which I expected, given the huge number of objects), but it doesn't completely lock up.

Cool, yes that's what I would expect too. It should work but will definitely stutter until the validation queue is drained - the work is done in chunks by requestIdleCallback. I can move this validation work off the main thread and into a web worker, then things will really perform better.

[dafadllyn]

I'm curious whether people have better luck with a version that has the validation improvements? Compare with this: https://mapwith.ai/rapid/59e1bd4-16.x-dist/index.html It shouldn't be over-validating entire routes anymore.

@bhousel: RapidiD isn't noticeably faster on the machine with a 2.4 GHz Intel Core i5-2435M processor neither in Bern, Switzerland (where it complains about 740 issues, mostly "two points in ... are very close together") nor in Chur, Switzerland (190 issues, mostly "... looks like a feature with incomplete/nonstandard tags").

[bhousel]

RapidiD isn't noticeably faster on the machine with a 2.4 GHz Intel Core i5-2435M processor neither in Bern, Switzerland (where it complains about 740 issues, mostly "two points in ... are very close together") nor in Chur, Switzerland (190 issues, mostly "... looks like a feature with incomplete/nonstandard tags").

Yes, it's going to depend a lot more on what spot of map that you're looking at, and what kind of features are there, and which ones you touch. It doesn't really depend much on what CPU you have.

[MarkusGaugg]

Is it known until when a bug fix can be expected in this regard? Working with iD is currently quite tedious due to the performance problems.

[FinixFighter]

I have the same problem. I use Linux Mint 20.2, Firefox 93.0, iD is extremely slow and laggy. I don't have an high end pc so iD it's quite unusable for me now (worked great before).

[mbrzakovic]

Hi all, thanks for raising this issue and apologies for making a late response. I did an investigation on this and have some news to share.

It seems that the major reason for slower perf in v2.20.x vs v2.19.6 is the increase in time in scripting, and more specifically time spent on preset matching.

I've just made an optimization in matchTag method that should give significant perf boost (by ~30% faster scripting). Please take a look at https://github.com/openstreetmap/iD/pull/8761, I've included a good explanations and some benchmark stats including comparison of current and v2.19.6 iD.

Additionally, the start-up time of iD has increased. On my laptop it takes ~20-30s for locations to bootstrap.

• I will look into this one more deeply, first thing that falls on my mind is to perform the 'locations bootstrapping' offline (in build time).

Finally the validator picks up more entities and few more rules have been added in comparison to v2.19.6.

[dafadllyn]

@mbrzakovic: Thank you for taking the time to address this issue. Could you please repeat your speed test at a more densely mapped place like e.g. Bern? (iD reports over 1,000 issues there, of which about 50% are not NSI-related.)

Please also consider changing the behaviour of the "Check" toggle under "Issues". Currently it checks everything in the background even if it is set to "My Edits".

[mbrzakovic]

@dafadllyn I just did some benchmarking on Bern. Test was: Start app, go to &map=2.00/0.0/0.0, wait 20-30seconds. Start recording, immediately go to map=18/46.94817/7.44410 Wait 140seconds, End recording.

Results (on my cpu): Before: 5s spend on dom rendering, 135s spent on scripting out of which matchTags took 110s (because locationsAt took 95s). App still hasn't processed the validation queue. (Getting full render after 60s)

After https://github.com/openstreetmap/iD/pull/8761: 5s spent on dom rendering, 70s spend on scripting (other is idle or rendering) out of which matchTags took 23s (because locationsAt took 2s). App has processed the validation queue (Getting full render after 20s)

Conclusion: More then x2 faster scripting and response time in densely populated areas.

Additionally, I've observed that checkOutdatedTags validation rule is heavy due to using inner nsi matcher that uses methods similar to locationsAt, so it is possible there is some room for improvement there.

As for your second ask, I need some time to look into validator :)

[dafadllyn]

@mbrzakovic: Thank you! That sounds promising! :)

[mbrzakovic]

The change is live on http://ideditor.netlify.com/. Can you confirm the perf improvement on your machines? I recommend opening up http://ideditor.netlify.com/ and https://ideditor-release.netlify.app/ side by side.

• In order to do a proper comparison please don't forget to wait ~20s after the app start (until the location index builds)

Here is the result I am getting

https://user-images.githubusercontent.com/78906108/138254147-1c9e7d7f-dde6-4256-b0d0-429276a414ae.mp4

[jleedev]

I'm seeing similar results. Goes from 70s to 50s (on this incredibly slow machine).

My test: Load https://ideditor.netlify.app/#background=PEMA_Orthoimagery_2018_2020&disable_features=boundaries&map=15.00/40.3463/-80.0537, wait for the editor to finish launching, then click zoom in to edit.

Old: New:

[dafadllyn]

@mbrzakovic: Please excuse my late reply. I can also confirm that 2.20.2 is significantly faster than 2.20.1. Scripting time has decreased from about about 65 s to about 22 s on my machine (2.4 GHz Intel Core i5). This is about the time during which iD is unresponsive and cannot be used for editing. However, even 2.20.2 is still much slower than releases prior to 2.20.

2.20.1:

2.20.2: