1913018 - storage.session.set / storage.session.get is slow with megabytes of JS objects

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[Mizuki Nguyen]

Attachment: A video of the non-responsiveness.

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

Steps to reproduce:

Create a fresh profile and install Tab Session Manager: https://addons.mozilla.org/en-US/firefox/addon/tab-session-manager/
In the addon's options menu, navigate to Sessions > Import URL List
Copy-paste around 200 lines of a URL, like "https://www.mozilla.org/en-US/" and click Import.
Click on the addon icon on the toolbar - there should be a session with 200 tabs - click on it and quickly close the tabs in the session. (the X icon at the right)

Actual results:

The extension becomes sluggish and non-responsive.
about:performance shows the extension process using a large amount of RAM and CPU.
Profiler: https://share.firefox.dev/46Mopjt

Expected results:

The extension should proceed smoothly.

I have confirmed this to be a Firefox issue as mozregression identifies the 2023-05-16-04-24-30-mozilla-central build to be the regression. (2023-05-16-04-24-30-mozilla-central works)
Unfortunately it seems build-every-commit is only kept for a year, so that's the most I could go with.

Comment 1

[Mizuki Nguyen]

(In reply to Mizuki Nguyen from comment #0)

Created attachment 9419015 [details]
A video of the non-responsiveness.

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

Steps to reproduce:

Create a fresh profile and install Tab Session Manager: https://addons.mozilla.org/en-US/firefox/addon/tab-session-manager/
In the addon's options menu, navigate to Sessions > Import URL List
Copy-paste around 200 lines of a URL, like https://www.mozilla.org/en-US/ and click Import.
Click on the addon icon on the toolbar - there should be a session with 200 tabs - click on it and quickly close the tabs in the session. (the X icon at the right)

Actual results:

The extension becomes sluggish and non-responsive.
about:performance shows the extension process using a large amount of RAM and CPU.
Profiler: https://share.firefox.dev/46Mopjt

Expected results:

The extension should proceed smoothly.

I have confirmed this to be a Firefox issue as mozregression identifies the 2023-05-16-04-24-30-mozilla-central build to be the regression. (2023-05-16-04-24-30-mozilla-central works)
Unfortunately it seems build-every-commit is only kept for a year, so that's the most I could go with.

Comment 2

[BugBot [:suhaib / :marco]]

This bug was moved into the Performance component.

:pridefulmizuki, 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

[Rob Wu [:robwu]]

(In reply to Mizuki Nguyen from comment #0)

I have confirmed this to be a Firefox issue as mozregression identifies the 2023-05-16-04-24-30-mozilla-central build to be the regression. (2023-05-16-04-24-30-mozilla-central works)

The two builds you mentioned are the same. I presume that 2023-05-16-04-24-30 is the build that "introduced" the regression. I suspect the regression to be caused by the introduction of a new API in that commit, storage.session (bug 1823713, https://hg.mozilla.org/mozilla-central/rev/532904ff2fff).

The profile has been redacted a lot to the point that there is barely any useful information to diagnose the issue. I ran the STR again to generate new profiles, including screenshots:

• https://share.firefox.dev/4crjt4L
• https://share.firefox.dev/4cy4t57

This second profile does not only include the STR, it also shows the size of the data stored with storage.session. After repeating the STR, the serialization of the data as JSON shows a jump from 5 MB to 7 MB. The profile shows that lots of time is spent on cloning the data, e.g. in the zoomed in second profile:

• WebExtensions process has 665ms jank, 525ms from cloneInto in preparation for sending the data from the storage.session.set call.
• WebExtensions process has 667ms jank, 68ms in deserializeForContext, 560ms in cloneInto, as part of sending the result of a storage.session.get (note: Get not Set) to the extension.

I tried to create a self-contained test case, where I load a few megabyte JSON object and pass it to storage.session.set, then call storage.session.get. I cannot see the bad perf issue observed with the original STR here, but can clearly see the same issue with storage.session.get.

Comment 4

[Rob Wu [:robwu]]

Attachment: storage-session-cloneInto.zip

Test case:

1. Load extension, e.g. at about:debugging or with web-ext run -f nightly -u profiler.firefox.com
2. Start the profiler.
3. Open the extension popup panel. Click om all buttons in the given order (load JSON data, clear storage if any, storage.session.set, storage.session.get)
4. Export the profile

Expected:

• No significant performance issue.

Actual:

• Profile shows 711ms jank, of which 603ms is in cloneInto: https://share.firefox.dev/3X648T1

Comment 5

[Rob Wu [:robwu]]

To cap the issue, the quota will be restricted in bug 1908925. But even with the quota (10MB), the issue as observed here will still happen. The test case in comment 4 has an object that is 8 MB when serialized as JSON without whitespace (14 MB when pretty-printed).

Comment 6

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:zombie, could you have a look please?

For more information, please visit BugBot documentation.