Open Bug 1356686 Opened 5 years ago Updated 3 months ago
OMT brotli decompression
See this profile for example: <https://perfht.ml/2og8OSq> I captured it by loading the facebook homepage. We spend 53ms on the main thread decompressing the brotli stream. I bet this is a lot worse on a slow machine. It seems we shouldn't be running decompression code on the target thread of the Necko data delivery. Even if the target thread isn't the main thread (for example for the HTML parser) it seems that blocking HTML parsing for data decompression is a pretty bad idea if the machine does have free cores to run more than one thing concurrently.
Marking as [qf:investigate:p1] because it's premature to assume that simply moving this OMT is going to make things faster, of course.
Whiteboard: [qf:p1] → [qf:investigate:p1]
BTW I have another profile as well: https://perfht.ml/2ofWYYD This is super easy to reproduce, FTR.
Whiteboard: [qf:investigate:p1] → [qf:investigate:p1][necko-next]
nsHTTPCompressConv doesn't implement nsIThreadRetargetableStreamListener so OMT is disabled if decompression is required. The first thing to try is to reenable OMT for this scenario, i.e. move the decompression overhead to parser thread instead of blocking main thread. I am not sure if moving decompression to another 'converter' thread will further improve the performance, since the HTML parser will still be waiting for the decompressed data. The page loading and rendering for HTML will still be blocked anyway. However, this will benefit the scenarios that OMT is disabled by other reason. It'll need further experiment to understand the benefit.
I'm not confident this will end up helping a lot either, but there are cases where we are fetching multiple compressed resources in parallel (js, css, html all commonly compressed) - so helper threads could at least give some parallelism.. but honestly this processing happens pretty fast so it might not be a win after the overhead.
FWIW I have seen this take 1-5 frames quite regularly in various profiles over the past few months, for example on Facebook. The example profile in bug 1367666 reminded me to comment here. It would really be nice if we fixed this, this really does show up a lot on real sites.
After bug 1357678 landed, part of the time we spent on brotli decompression is off-main-thread now (for example HTML parsing and image decoding). The reset of brotli decompression loading on main thread is mainly for loading JS and CSS. Bug 1380218 and bug 1381425 were filed previously for further OMT JS/CSS loading.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
Dragana - is this something you can tackle?
Priority: P2 → P3
Whiteboard: [qf:investigate:p1][necko-next] → [qf:investigate:p1][necko-triaged]
Whiteboard: [qf:investigate:p1][necko-triaged] → [qf:p1:pageload][necko-triaged]
Assignee: nobody → brennie
Status: NEW → ASSIGNED
Assignee: brennie → nobody
Status: ASSIGNED → NEW
Performance: --- → P1
Whiteboard: [qf:p1:pageload][necko-triaged] → [necko-triaged]
You need to log in before you can comment on or make changes to this bug.