1904284 - Opening https://colorjs.io/ keeps the parent-process very busy for 4+seconds, spending tons of time in network-y IPC. This results in stutter while scrolling

Status: REOPENED

(Core :: Networking, defect, P2)

Description

[Mayank Bansal]

1. Go to https://colorjs.io/
2. Wait patiently till the page loads fully (may take 10-15 seconds)
3. Keep on scrolling from top-to-bottom

AR:
Nightly: https://share.firefox.dev/4bjwSLP
Chrome: https://share.firefox.dev/3xl7CqJ

ER: Maybe something to improve?

Filing this under Core:networking, but this may be DOM:PostMessages.
cc: valentin, smaug
The profile is similar to bug 1883290

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

This appears to all be communication with WebExtensions; likely due to ublock origin. Looks like something where the page makes a zillion small requests (~300 bytes) for js files, and ublock origin has to tell the parent process if each one is ok. Probably this is simply required due to how ublock origin works; you should ask them if there's anything they (or we) could do to improve this, but likely it's just the way it is if a page is constructed this way.

You might check if that other report is the same issue. It's always helpful to check a repeatable bug with troubleshooting mode or a new profile, which can speed diagnosis.

Thanks for reporting!

Comment 2

[Mayank Bansal]

(Reopening only this one time)

See a profile from a fresh Nightly profile with no addons: https://share.firefox.dev/4bmM7Ue
Edit: And a profile with all threads sampled : https://share.firefox.dev/3zhnuet

Comment 3

[Mayank Bansal]

Attachment: about:support

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Mayank - thanks for the no-extensions profile. It's possible there's something we can improve here; the site certainly stresses the network layer by a very large number of small loads. I note that Chrome is also very busy when you scroll down this page. I don't see stuttering on my system/network, but that may vary depending on CPU/network/etc.

See for example https://share.firefox.dev/4bkNrqS

Andrew, kershaw: thoughts?

Comment 5

[Mayank Bansal]

An additional observation: In all the profiles from comment #2 (https://share.firefox.dev/4eJqFMf, https://share.firefox.dev/4cB1bi6) and comment #4(https://share.firefox.dev/3W2jhEp), the parent process appears to spend 700-800ms in font loading code (maybe not 100% but a large majority)

Comment 6

[Kershaw Chang [:kershaw]]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #4)

Mayank - thanks for the no-extensions profile. It's possible there's something we can improve here; the site certainly stresses the network layer by a very large number of small loads. I note that Chrome is also very busy when you scroll down this page. I don't see stuttering on my system/network, but that may vary depending on CPU/network/etc.

See for example https://share.firefox.dev/4bkNrqS

Andrew, kershaw: thoughts?

I think it would be difficult to reduce the main thread loading in the parent process.
However, I do see an opportunity here. From the all-thread sample, I notice that the ProxyResolution thread uses ~30% CPU resources. I think it would be beneficial to revisit bug 1392272 (which was reverted in bug 1749501) to avoid reading system proxy settings for every HTTP request.

Comment 7

[Andrew Creskey [:acreskey]]

(In reply to Kershaw Chang [:kershaw] from comment #6)
...

I think it would be difficult to reduce the main thread loading in the parent process.
However, I do see an opportunity here. From the all-thread sample, I notice that the ProxyResolution thread uses ~30% CPU resources. I think it would be beneficial to revisit bug 1392272 (which was reverted in bug 1749501) to avoid reading system proxy settings for every HTTP request.

I've logged optimizing the proxy resolution in bug 1907364

Comment 8

[Sunil Mayya]

Hello Andrew, as we are planning improving our CPU utilization with Bug 1907364, I don't think we can do anything additional for this bug?

Comment 9

[Andrew Creskey [:acreskey]]

(In reply to Sunil Mayya from comment #8)

Hello Andrew, as we are planning improving our CPU utilization with Bug 1907364, I don't think we can do anything additional for this bug?

I think it's fine to leave it open as blocked by bug 1907364

Comment 10

[Bas Schouten (:bas.schouten)]

The Performance Impact Calculator has determined this bug's performance impact to be low. 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 [x] Android
Websites affected: Rare
Resource impact: Severe
[x] Able to reproduce locally