Currently we use a simple heuristic based on the size of the script / encoded content to decide whether we should parse/decode off-main thread. Unfortunately, we have no way to ensure that we can safely compare both. Based on density of the script size about 1024 bytes, and the density of encoded content (assuming that the encoding size is proportional to the source length, which it is not). We can deduce that the size factor is 3.67, which roughly corresponds to what is observed with the low and max bounds of sizes. Based on this factor, this implies that P(decode_MT | parse_MT) = 64.36% P(decode_OMT | parse_MT) = 35.64% P(parse_MT | decode_OMT) = 55.37% P(parse_OMT | decode_OMT) = 44.63% If we were to change the heuristics of CanCompileOffThread to include this 3.67 factor inside this heuristics (for telemetry reasons), then we would almost have a 1-to-1 mapping between scripts which are parsed and decoded on the main thread, and the script which are parsed and decoded off-main-thread. Thus obtaining something closer to: P(decode_MT | parse_MT) = ~100% P(parse_OMT | decode_OMT) = ~100% This might not be the ideal solution, but this would at least give us some data on whether the JSBC is improving or not.
Created attachment 8887552 [details] [diff] [review] Hard-code the current size factor between the source size and the bytecode size.
Created attachment 8887553 [details] [diff] [review] Hard-code the current size factor between the source size and the bytecode size.
Attachment #8887553 - Flags: review?(mrbkap)
Attachment #8887553 - Flags: review?(mrbkap) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b268982e5a34 Hard-code the current size factor between the source size and the bytecode size. r=mrbkap
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.