Open
Bug 1440000
Opened 6 years ago
Updated 2 years ago
Code on https://flow.org/try is a lot slower in Firefox than in Chrome, causes hangs
Categories
(Core :: JavaScript Engine: JIT, defect, P2)
Core
JavaScript Engine: JIT
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox60 | --- | affected |
People
(Reporter: julienw, Unassigned)
Details
STR: 1. Load an example, for example [1]. (sorry for the big link, but all the content is encoded as a hash) => After loading the URL, a JS build of Flow is initializing. That's already slower in Firefox than in Chrome. 2. Then try to edit the code. For example simply try to add more text in the comment in the second line. => You get hangs while you type. In Chrome there isn't such hangs. Surely they could try to throttle the code editing events. But because Chrome behaves fine this should be the case in Firefox too. [1] https://flow.org/try/#0PTAECUFMFpIDwA4HsBOAXUaAWkDOlQcUDclMcBPUAQ2NEmtwEsAbK6gN2teoCMWCAMxRIAtqADuRSB0goaAOwAmNDkiZLcAKBCgAxkxR6Ari1qglkBJGU2DeAHRa0Fa6ACCetEyQLQAXlAAbwAfTFdIAC5QAHIAZQB5AFkAUQB9dwBhABUASQSAORjQEIBfEuCwl2tomPcChOyACRTwDJz8ooAaUAQRBGjcNBQmBQBzEtKAbmcI0Di0ajQCQNDQQSQkaIVjUV45SZmdMHAAiDxTDCRBGnJjBQBrGi8fBVm3bKx7h4ARJlwEEs9FgzgAecAAPgAFNQXr5op9vp5vL5wRCAJQBCEQGbVAgABTMoz+AKBIMCoPc0WRr2hsJRCmpmP82PcuLmAHFIGgFksVqAoczsbzluyPl9HjTUZCzlClP9AWhgdESYrgT0uTzFsshTjjqBPgQAAby0lKrBG9b3OF+PTUPywvRWDCQJjYA7UXpEh020CoW7Yb7PBlOXSff6gCPMUQ8eRoMievGgI0wm3U31hRGSm26+0US3wJ0IDDYf766gsFhICS4TBkJPu0DENDGFB+LgsYwERiSSCVpxJ1Vks6E7gKIfm0AAMgNEt+CrJRyTKTgw3pUBbbeycwpkKhUIch+IQ2ied14HPM1A19AWkE1oZwdemWIS1QguCWhvN+brb8QS-b8bzxWpElSdo8kKGJAO-aYtFKGDb3vBRfUDbMGRfBh4xQGEUDGQZhlGMZ0QROcpQUUEdj2ORsQAoCm25P8BVNNUsB6MZuRFSBdTo+iLAXc0oSCcIaliepGhaNoskg7pen6U88NAUp0SvPjfzbUAAGZVNgmYEO-LRLD0Mw6C4eQWLJFUBOBGY5WsrAoTQh5yMwt8cJiDYkBidESNAKj9hQFStDss1gVTDDX2wwVfLWEDYjA9JpM6YoyiCgyDL0Xwhn40KsHxfpa1WRDryclzItQLpiqfXxXOwyq4IMpNyPypAEEK0AABIV3pUEOoSXgACskmoBBQTxa4ctYlq2p6Fc1y8Dc-23awIQhI4hMA+ln3KlBTxtWr33RSqSrI-aduiUqzqw98PM2bz6vTBlptwIL3gICdgUgJRnrOLq4B6vrBuG0bmoKnoPqwValzmCGvtBfFsUCP6Af6oaRt61Hgfh2bVxQddGK3CIIXB+yoa0YLeK2mrzsmslwu266cJ8467nQhm3OiCzBMuiLGahW6vOZ+CrNyr7ntejbryphQDt22nBOl2XopZnn2ewzn7Mc07ebc-nPO8o7hdAWGlDGiIJq54FnoxI43tAAAxa0ftWEJNqujmBR4qoIlA5JEo6KDJhV7W1dQaIoSGEZxl1fy5EqsojmQ31MoUBRIC8UEIee6JUfTtBoUEcOBgdp2Ct1NQNB6Yus7Lz9r0EKEECChC7wfV4rRQxvokdlDxbrgUEAcVXqb5gXvO2XYAub8mU7TrwoSTnpLbysujiAA perf profile: https://perfht.ml/2BH3YrN Especially look at the big hangs at the end of the profile. For example there are 2 big block of js::jit::MIRGraph::removeSuccessorBlocks taking each ~250ms. Note: Flow is a static javascript analyzer that involves typing. This is made in Caml. The Flow try interface makes it easy to try things and report problems to them. The script that's run here is https://flow.org/static/v0.66.0/flow.js, generated using js_of_ocaml [2], which doesn't make this easy to analyze. [2] http://ocsigen.org/js_of_ocaml/.
Comment 1•6 years ago
|
||
Based on the profile, we spend 25% under IonCompile.
Component: JavaScript Engine → JavaScript Engine: JIT
Priority: -- → P2
Comment 2•6 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #0) > For example there are 2 big block of > js::jit::MIRGraph::removeSuccessorBlocks taking each ~250ms. This is restartLoops I think. We should check why removeSuccessorBlocks is so slow, maybe it's doing something stupid, and we're probably also inlining/compiling too much.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•