Closed Bug 1202697 Opened 9 years ago Closed 4 years ago

[meta] Slow JSM module imports

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: esawin, Assigned: esawin)

References

Details

(Keywords: meta, perf)

Attachments

(8 files, 4 obsolete files)

Compile times [cached, default settings]
20.07 KB, text/plain
Details
Execution times [default settings]
20.07 KB, text/plain
Details
Compile times [cached, baseline-jit=false]
20.07 KB, text/plain
Details
Execution times [baseline-jit=false]
20.07 KB, text/plain
Details
Compile times [cached, baselineWarmUpThreshold=5]
19.54 KB, text/plain
Details
Execution times [baselineWarmUpThreshold=5]
19.55 KB, text/plain
Details
Compile times [cached, baselineWarmUpThreshold=15]
19.55 KB, text/plain
Details
Execution times [baselineWarmUpThreshold=15]
19.55 KB, text/plain
Details
Importing JS(M) modules can be slow on Fennec and has negative effect on startup performance. In this bug, we'll collect some analysis regarding slow imports and keep track of potential optimization bugs.
Assignee: nobody → esawin
Blocks: 807322
Keywords: perf
Attached file Nexus 7 startup import times (obsolete) —
Attached file Nexus 7 startup script execution times (obsolete) —
Depends on: 1207191
Attachment #8664262 - Attachment mime type: text/x-log → text/plain
Attachment #8664263 - Attachment mime type: text/x-log → text/plain
1371ms just to compile js? ಠ_ಠ
Depends on: 1191351
Attachment #8658223 - Attachment is obsolete: true
Attachment #8664262 - Attachment is obsolete: true
Attachment #8664263 - Attachment is obsolete: true
Attachment #8664370 - Attachment is obsolete: true
According to local logs (attached to bug) and autophone [1], script compile/execution times on Fennec startup seem to be lower across devices (and test pages) with baseline JIT disabled. Naveed, is this expected or surprising? Any ideas on how to improve this on mobile devices? [1] http://phonedash.mozilla.org/#/org.mozilla.fennec/totalthrobber/local-nytimes/norejected/2015-09-28/2015-10-05/cached/noerrorbars/standarderror/try
Flags: needinfo?(nihsanullah)
Nicolas could you please take a look?
Flags: needinfo?(nihsanullah) → needinfo?(nicolas.b.pierron)
I have not investigated yet, but I recall that b2g had a similar issue, and the work-around that they made was to use only one global for all JSM. I do not recall if this was more a memory issue than a load time issue.
Can you submit the patches that you have used to submit these results, to make sure we can interpret correctly these result.
Flags: needinfo?(esawin)
(In reply to Eugen Sawin [:esawin] from comment #10) > According to local logs (attached to bug) and autophone [1], script > compile […] What do you call compile time? Is this only from the parser to the bytecode emitter? Baseline should have no impact on the bytecode compilation. (In reply to Eugen Sawin [:esawin] from comment #10) > […], script > execution times on Fennec startup seem to be lower across devices > (and test pages) with baseline JIT disabled. A while ago, I looked at b2g, and we had some JitRuntime initialization cost of about 25ms per Runime. But this cost should only appear on one unique script. Then it might be that our heuristics do not match your work-load and that the creation of Baseline code, and ICs is creating an initial cost which is visible here. Note that disabling baseline also disable IonMonkey, which might use more additional time / threads for compiling. Maybe you can re-try with different values of JIT_OPTION_baselineWarmUpThreshold environment variable, such as 5 and 15. (default is 10) [1] [1] https://dxr.mozilla.org/mozilla-central/source/js/src/jit/JitOptions.cpp#141
(In reply to Nicolas B. Pierron [:nbp] from comment #13) > Can you submit the patches that you have used to submit these results, to > make sure we can interpret correctly these result. Commit to switch baseline-jit off by default: http://hg.mozilla.org/try/rev/5e516499d476 Autophone results with baseline-jit enabled and disabled: http://phonedash.mozilla.org/#/org.mozilla.fennec/totalthrobber/local-blank/norejected/2015-09-28/2015-10-05/cached/noerrorbars/standarderror/try To get the local logs, I've hooked some logging into JSComponentLoader, here is the full testing branch: https://github.com/eamsen/gecko-dev/commits/perf (CPU time logging is based on bug 1193821 but is not strictly required)
Flags: needinfo?(esawin)
Thanks for describing the instrumentation, so what you call Compile time is the parser, and the Parser should not be influenced in any way by the fact that the Baseline Jit is enabled or not. The Baseline compiler runs during the execution, while the Compile function is used to generate the bytecode and AsmJS compilations. Based on the "Compile times" results that are attached to this bug (root normalized-max): - no baseline = ~908 - baseline 5 = ~942 - baseline 10 = ~978 - baseline 15 = ~826 All of these results should be identical, based on the scope that you took to measure the Compile function time. So the noise level seems to be of at-least of ~20%. Then looking at the execution times. As said above, the execution time include baseline compilation as well as its IC. So it might have a negative impact if you run most functions ~10 times during the start-up. You basically got the following results (root normalized-max): - no baseline = ~693 - baseline 5 = ~752 - baseline 10 = ~770 - baseline 15 = ~632 So, based on the previous measurement, these results seems to be within the noise level of the Compile function time. (In reply to Eugen Sawin [:esawin] from comment #10) > According to local logs (attached to bug) and autophone [1], script > compile/execution times on Fennec startup seem to be lower across devices > (and test pages) with baseline JIT disabled. So I do not think the result that you attached are showing that disabling all the Jits(*) plays any role, as the noise level seems to high to draw any conclusion. The way the JavaScript language is defined means that we are unlikely to be able to optimize the start-up time of the execution, but I would be interested if you could measure the effect of enabling the XDR cache on the JSM. From what I recall this was one of the optimization we did on the browser, and both Google and Apple did the same thing for JS web pages. Normally we should already have some caching of the bytecode use for these modules, but the fact that the Compile function is even taken highlights that you are not even using the XDR cache. (*) Disabling baseline as the side-effect to also disable IonMonkey, which probably means you are more likely to slow the rest of the execution of the browser later.
Flags: needinfo?(nicolas.b.pierron)
Keywords: meta
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: