Chrome enables its TurboFan compiler when it seems asm.js content. There might be a chrome flags:// option to disable TurboFan, so you can try to see if flipping that matters (or maybe a commandline flag). I don't think there is any logging in the console for when TurboFan is used, unlike in Firefox and Edge.
I would file a bug on Chrome even without a very specific testcase. It's enough to provide a link and say "this site runs 3x slower in Chrome" (with a way to measure speed, like an fps counter). If they need further info they can ask for it, but often they can quickly triage such things themselves. On Tue, Aug 11, 2015 at 11:54 PM, Laurent Pugin <[email protected]> wrote: > Thanks for your answers. Firefox running time is indeed roughly the same > as native. The reason why I thought in the first place asm was not taken > into account at all in Chrome is because the execution time is three to > four times slower than in Firefox but also pretty much the same as with a > browser with no asm support (e.g., Safari). See it here (loading time in > the console) > > http://www.verovio.org/mei-viewer-debug.xhtml?examples/downloads/Hummel_Concerto_for_trumpet.mei > > Is there a way to see in Chrome if it is actually compiling to asm? > > Otherwise I will try to isolate a test case and file a bug to Chrome if I > can reproduce it. > > On Tuesday, 11 August 2015 18:46:47 UTC+2, Alon Zakai wrote: >> >> > it might be useful to file a ticket in the Chromium issue tracker >> >> I agree, it sounds like a perf bug in Chrome. Best thing is to file an >> issue for them to take a look at. >> >> On Tue, Aug 11, 2015 at 8:19 AM, Floh <[email protected]> wrote: >> >>> No, sorry, no idea. I try to avoid the C++ RTTI system ;) >>> >>> I was thinking about tweaking the outlining-limit (see: >>> http://mozakai.blogspot.de/2013/08/outlining-workaround-for-jits-and-big.html), >>> if the generated code contains very large functions, JS engines may not >>> optimize them. I was bitten by this problem a long time ago with sqlite. If >>> this would be a problem you would get warnings about large functions in the >>> linker step. >>> >>> But dynamic_cast, I have no idea what the problem could be... even if it >>> is used heavily I couldn't imagine what would be so expensive about it. >>> >>> Is the performance in Firefox roughly the same as a native optimized >>> executable, or is this also a lot slower? >>> >>> An isolated test case might be helpful, it could actually be a more >>> serious code generation issue and/or a pathological case for Google's JS >>> engine (in this case it might be useful to file a ticket in the Chromium >>> issue tracker). >>> >>> Cheers, >>> -Floh. >>> >>> >>> Am Dienstag, 11. August 2015 16:05:39 UTC+2 schrieb Laurent Pugin: >>>> >>>> >>>>> I would advice to compile your code with optimization on and -g2 >>>>> (preserves function names), and then use Chrome's JS profiler (part of >>>>> Chrome Developer Tools panel). This should give you an idea what functions >>>>> are especially slow and perhaps provide a hint which C/C++ code is the >>>>> problem. >>>>> >>>> >>>> It seems that dynamic_cast takes quite some of the time (nearly 50%?). >>>> Any thoughts? >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
