Open Bug 1510262 Opened 2 years ago Updated 1 month ago
Incremental Download causes a lot of jank with main thread I/O while downloading updates in the background
See this profile captured on the 2018 reference hardware: https://perfht.ml/2RiiwTM 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.
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   https://searchfox.org/mozilla-central/rev/0859e6b10fb901875c80de8f8fc33cbb77b2505e/netwerk/base/nsIncrementalDownload.cpp#60
Component: Networking → Networking: HTTP
Priority: -- → P2
Whiteboard: [qf:p2:responsiveness] → [qf:p2:responsiveness][necko-triaged]
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
Following calls hit PR_Close(): OnStartRequest: https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/netwerk/base/nsIncrementalDownload.cpp#616 OnDataAvailable: https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/netwerk/base/nsIncrementalDownload.cpp#690 OnStopRequest: https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/netwerk/base/nsIncrementalDownload.cpp#653 Solution: - retarget the channel to stream transport service - have a task queue, as at  - 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  https://searchfox.org/mozilla-central/rev/3160ddc1f0ab55d230c595366662c62950e5c785/netwerk/base/nsNetUtil.cpp#1433-1447
Status: NEW → ASSIGNED
https://perfht.ml/2GFHcEG 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.
You need to log in before you can comment on or make changes to this bug.