Open Bug 1510262 Opened 4 years ago Updated 4 months ago

nsIncrementalDownload causes a lot of jank with main thread I/O while downloading updates in the background


(Core :: Networking: HTTP, defect, P3)




Performance Impact medium


(Reporter: florian, Unassigned, NeedInfo)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: perf, perf:responsiveness, Whiteboard: [necko-triaged][bhr:nsIncrementalDownload])

See this profile captured on the 2018 reference hardware:

This is happening when downloading an update in the background, which can happen while the user is attempting to load pages. Especially as this background update download tends to happen soon after startup.
Whiteboard: [qf] → [qf:p2:responsiveness]
The jank occurs on closing the fd,
and we did the fd open and close every ODA.

We might only close the fd on OnStopRequest, but it's risky to modify super old code [1]
Component: Networking → Networking: HTTP
Priority: -- → P2
Whiteboard: [qf:p2:responsiveness] → [qf:p2:responsiveness][necko-triaged]
(In reply to Junior Hsu from comment #1)

> We might only close the fd on OnStopRequest

Ideally the whole thing should move off main thread. We only need to send something back to the main thread if we have JavaScript code on the receiving end. shows we have hangs for the PR_Close that you pointed, but we also have some for PR_Write and for OpenNSPRFileDesc.
Agree, this has to move to a different thread.  Is this is a recent regression?
(In reply to Honza Bambas (:mayhemer) from comment #3)
> Is this is a recent regression?

I don't think so, I already noticed this behavior when profiling for Quantum Flow / Firefox 57. It's more likely to be the last occurence that remains of something that was kinda OK a decade ago.
Honza is this something you can tackle?
Assignee: nobody → honzab.moz
Flags: needinfo?(honzab.moz)
Following calls hit PR_Close():


- retarget the channel to stream transport service
- have a task queue, as at [1]
- all writes to the file will happen there
- all notifications (start/progress) must go the main thread and after file operations (truncate in onstart, final write on onstop) are done; this is a precaution, not something I checked on we really must do

Flags: needinfo?(honzab.moz) has us janking for a combined total of about 15 seconds (7k samples on Windows for nsIncrementalDownload::FlushChunk, plus some more elsewhere) because it's downloading a complete mar file, on the reference hardware with its disk + cpu contention... fixing this bug would really help quite a lot for those cases.

I find the jank in this startup profile even more impressive: Probably because I was using the fast internet connexion on a machine with slow I/O, so the main thread I/O blocked the whole time.

This could be nicely fixed with bug 1528285. Looking more into the code, observer is only an nsIRequestObserver which we can easily dispatch to the main thread. Then there is mProgressSink, for which we can do the same.

Adding dep, should it significantly delay, I can move only the writes/flushes to a bck thread.

Depends on: omt-networking
Assignee: honzab.moz → nobody
Flags: needinfo?(gijskruitbosch+bugs)
Whiteboard: [qf:p2:responsiveness][necko-triaged] → [qf:p2:responsiveness][necko-triaged][bhr:nsIncrementalDownload]
Priority: P2 → P3
Performance Impact: --- → P2
Whiteboard: [qf:p2:responsiveness][necko-triaged][bhr:nsIncrementalDownload] → [necko-triaged][bhr:nsIncrementalDownload]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.