Closed Bug 1052342 Opened 11 years ago Closed 11 years ago

AWFY Flame Kraken: 5.5% regression

Categories

(Core :: JavaScript Engine, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: nbp, Unassigned)

Details

The following is from the log of the harness which automatically updating the phone: Aug 12 07:46:42: From https://git.mozilla.org/integration/gecko-dev Aug 12 07:46:42: e8ebcb5..a40ca1f inbound -> gmo-integration/inbound http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2c8eb8d36d197c49099201f5aa38177027851ad3&tochange=826764ae5063e5caf815e6cdc53e8e6a8080a342 Aug 12 07:46:44: From https://git.mozilla.org/releases/gaia Aug 12 07:46:44: 254ecd8..bb825aa master -> mozillaorg/master https://github.com/mozilla-b2g/gaia/compare/254ecd8...bb825aa The regression can be seen on all kraken benchmarks: http://arewefastyet.com/?a=b&view=regress#machine=26&view=single&suite=kraken&subtest=darkroom&start=1407812832&end=1407835945 I doubt this could be caused by the backout seen on mozilla-inbound knowing that the patch did not improved performances before that. Maybe this is related to Bug 1052239, which landed before the backout and remained after. Otherwise, the only remaining possibility is that Gaia changes might be consuming extra resources when kraken is running. I have no idea how the system/lockscreen changes can cause such slow down. The benchmark is ran as follow: - Changes are fetched. - All repositories are synced & build. - Partitions are flashed. - Marionette [1]: - Unlock the lock screen - Connect to the Wifi - Start the browser application - Browse http://people.mozilla.org/~npierron/kraken/hosted/ - Wait 60 seconds and click "Begin". - Wait 8 minutes. - Collect the result. [1] https://github.com/nbp/gaia-ui-tests/blob/bench/gaiatest/tests/browser/benchmarks/test_bench_kraken.py (sorted as part of the JavaScript engine until we figure out where it should go)
This could be bug 1043892. I would set a console.log in the setInterval() at https://github.com/mozilla-b2g/gaia/commit/5f7d9e2813bc4719919f5b6b52219295c56ebb13#diff-2c311690d89bf697f6f1ff86345cb26eR54 to verify it is fired during the benchmarks.
My commit is only a backout of a failing commit, it's very less likely that's the cause of the regression.
If it's the cause, I may change the event queue to use Promise-based solution to implement it. However, since the queue is not a major part of the patch, I would suggest to fix it on a new bug, rather to backout the whole state manager in Bug 1043892.
A similar slow down is visible on Unagi (GGC) [1], while running Sunspider benchmark[2]: Aug 12 07:33:28: From https://git.mozilla.org/releases/gaia Aug 12 07:33:28: 254ecd8..3989fd4 master -> mozillaorg/master https://github.com/mozilla-b2g/gaia/compare/254ecd8...3989fd4 Aug 12 07:34:42: From https://git.mozilla.org/integration/gecko-dev Aug 12 07:34:42: e8ebcb5..a40ca1f inbound -> gmo-integration/inbound (same as above) Which excludes Bug 1045919. [1] http://www.arewefastyet.com/#machine=14&view=single&suite=ss&subtest=aes&start=1407805498&end=1407842145 [2] https://github.com/nbp/gaia-ui-tests/blob/bench/gaiatest/tests/browser/benchmarks/test_bench_sunspider.py
Most of the links in comment 0 and comment 4 are giving a 404 failure for me. If I've been CC'd because of the patch bug 1050036, then I'm confident it's not relevant because that's the patch that nigelb backed out (see comment 2).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.