Delay introduced by AsyncUrlChannelClassifier::CheckChannel()
Categories
(Core :: Networking, defect, P2)
Tracking
()
People
(Reporter: acreskey, Unassigned, NeedInfo)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [necko-triaged])
We're seeing delay introduced by AsyncUrlChannelClassifier::CheckChannel() in the main thread of the parent process
A profile from M1 Max MacBook Pro:
https://share.firefox.dev/3HFoue2
It looks like all of the AsyncUrlChannelClassifier::CheckChannel - return - priority: Normal (4) runnables end up queuing up, so the later ones will be significantly delayed. Visible in this profile:
https://share.firefox.dev/3Dth4rE
This code path, from asyncOpen in the content process to transaction pending on the parent process socket thread, looks to be one of the larger sources of latency within Necko.
(See Results - [meta] Review performance telemetry/markers)
This bug is to see what can be done to optimize this.
|
Reporter | |
Comment 1•2 years ago
|
||
The use of moz_log-to-profile markers has skewed these results, I'll recapture.
|
|
Reporter | |
Comment 2•1 year ago
|
||
Adding observations from Randell in #necko
On cnn.com he's seeing a 27ms cost to channel classification, mostly on mutexes for memory allocation/deallocation:
So I was looking at targets for OMT, and came across some stuff in a profile that may be a performance target (not for OMT). This is from a load of cnn.com, zoomed into an early part of the load when it's pulling in a bunch of images. Note that for 27ms, we're almost solely handling ChannelClassifier runnables (see the bottom of the Marker view). On top of that, for most of that 27ms, we're waiting on mutexes for memory allocation and deallocation (strings, arrays, etc). https://share.firefox.dev/4aTt5Vn If you zoom out, you'll see other bunches of ChannelClassifier runnables.
This smells like something that can be improved and would positively impact pageload.
Description
•