We need Telemetry on [OS.File] worker launching speed
Categories
(Toolkit Graveyard :: OS.File, defect)
Tracking
(Not tracked)
People
(Reporter: Yoric, Unassigned)
Details
(Keywords: perf, Whiteboard: [Async] [feature] [c=automation p= s= u=])
Investigating bug 959130, we realized that launching a Chrome Worker can be very slow (e.g. 200ms+ on a fast machine), which makes these workers unusable during startup – in particular, this means that we cannot (yet) use OS.File during startup. Telemetry on this would be useful.
Updated•10 years ago
|
Reporter | ||
Comment 1•10 years ago
|
||
According to http://telemetry.mozilla.org/#nightly/29/OSFILE_WORKER_LAUNCH_MS, the 95% percentile is over 2.5 seconds. That's very bad.
Updated•10 years ago
|
Updated•10 years ago
|
Comment 2•2 years ago
|
||
(In reply to David Teller [:Yoric] - still alive but not very active from comment #1)
According to
http://telemetry.mozilla.org/#nightly/29/OSFILE_WORKER_LAUNCH_MS, the 95%
percentile is over 2.5 seconds. That's very bad.
Today this looks like:
5th Percentile
3.54
25th Percentile
8.13
Median
31.36
75th Percentile
118.67
95th Percentile
935.36
Still not great for the 95th percentile. Assuming that this is not a general worker issue as most of the times worker startup seems fast I'd move investigations to OS.File, though.
Reporter | ||
Comment 3•2 years ago
|
||
If my memory serves, we suspected that the problem was related to cache contention.
Regardless, since the only users of ChromeWorkers are OS.File and the Thumbnail service, iirc, and the former is going away, I don't think that this has high priority.
Reporter | ||
Comment 4•2 years ago
|
||
If my memory serves, we suspected that the problem was related to cache contention.
Things may have changed in 8 years, though :)
Comment 5•2 years ago
|
||
Mass closure: OSFIle is being replaced with IOUtils and PathUtils. If you think this bug was closed in error, please re-open.
Updated•11 months ago
|
Description
•