1946264 - OpenStreetMap: Rapid Editor hitches severely

Status: UNCONFIRMED

(Core :: Performance, defect)

Description

[Atmospheric Ignition]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

I went to edit OpenStreetMap using the Rapid editor (rapideditor.org/edit), and quickly found out the site performs very poorly in Firefox, but it's performance is significantly better in other browsers on every platform I tried.

Using the editor doesn't require account to use. The datasets I enabled in the attached profiler captures are:
Facebook Roads
Microsoft Buildings
Overture Places
Open Data Footways
United States Addresses

Actual results:

The Rapid OpenStreetMap editor, found at rapideditor.org/edit, hitches frequently while editing, making it very difficult to use, since mouse drags and other inputs can have significant delay.
The general performance isn't much worse than the other browsers on different platforms I tried (Chromium, Safari and Firefox on both Linux and macOS), but the hitches which can occur as frequently as every 5 seconds, and last for more than a second are a real problem when you are trying to scan large swatches of satellite imagery for buildings and other features.

Profiler captures:
https://share.firefox.dev/42IF7Aw
https://share.firefox.dev/3EnrHzA
(the captures are very short because the FF profiler refuses to work after capturing any more than a few seconds)

Expected results:

The editor should not have frequent, severe hitches that make work difficult.

Comment 1

[Atmospheric Ignition]

Originally reported in 837985. The Rapid Editor is a modified version of OSM's iD editor. I've had similar hitching issues in iD, but unlike with Rapid, they haven't been severe enough to prevent me from using iD in Firefox.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

This bug was moved into the Performance component.

:atmign, could you make sure the following information is on this bug?

• ✅ For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 3

[Atmospheric Ignition]

Attachment: Memory report

Comment 4

[Atmospheric Ignition]

Attachment: about:support

Comment 5

[Atmospheric Ignition]

The GC logs are too large to attach to Bugzilla, please let me know if you want me to send them over some other channel.

Comment 6

[Bas Schouten (:bas.schouten)]

Any chance you could retest with the latest nightly? I'm hoping https://bugzilla.mozilla.org/show_bug.cgi?id=1943241 made a significant improvement here. The build in the profiles appears to be from one day before that landed!

Comment 7

[Atmospheric Ignition]

I just did a quick side-by-side comparison and ran a profiler capture of the latest nightly build from the Mozilla website vs. the release version from the Arch Linux repositories. It felt like Nightly was noticeably faster initially, but the performance very quickly wore back down. Obviously very subjective. Doing this on macOS (subjectively) felt the same.

Release
Nightly

Comment 8

[Atmospheric Ignition]

(In reply to Atmospheric Ignition from comment #7)

I just did a quick side-by-side comparison and ran a profiler capture of the latest nightly build from the Mozilla website vs. the release version from the Arch Linux repositories. It felt like Nightly was noticeably faster initially, but the performance very quickly wore back down. Obviously very subjective. Doing this on macOS (subjectively) felt the same.

Release
Nightly

By "felt the same" I mean the performance difference between nightly + release felt roughly the same on macOS as it did on Linux.
While I felt like the number of stutters didn't improve, I feel there has been improvement in the "harshness" of the stutters, where the stutters in nightly feel less like hitting a brick wall.

Comment 9

[Jan de Mooij [:jandem]]

Two questions:

1. Do you see the slowness after making some edits or also without? If it requires editing the map, do you just draw some lines?
2. Is it possible to share the URL for a location on the map where you see the slowness?

On Mac I see a lot of jank in both Firefox Nightly and Chrome but I want to make sure I have the right steps to reproduce.

Comment 10

[Atmospheric Ignition]

Here you go. Under "Rapid assist", check that "Facebook roads", "Microsoft buildings", "United States Addresses" and "Overture Places" are checked as data sources.

There absolutely is jank in any browser I tried, but the threshold for getting jank in Firefox is significantly lower than in Chromium in my experience. The jank seems to get worse in Firefox after a while of using the editor, but less severe symptoms can be observed immediately. What's strange is that I have experienced jank even at very low zoom levels in sparsely populated areas.

There is a separate performance issue related to having a lot of pending edits in the editor (seemingly related to json handling).

Comment 11

[Bas Schouten (:bas.schouten)]

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: [x] Windows [x] macOS [x] Linux
Impact on site: Causes noticeable jank
[x] Affects animation smoothness
[x] Able to reproduce locally

Comment 12

[Atmospheric Ignition]

I just noticed that during many operations (zooming, panning, even over sparse areas), Chromium will use multiple threads (4 - 7 CPU threads on a 32 thread system), while Firefox will just peg a single CPU thread.