- From: Katelyn Gadd <kg@luminance.org>
- Date: Sun, 22 Jun 2014 20:17:16 -0700
- To: Stéphane Letz <letz@grame.fr>
- Cc: "public-audio@w3.org Group" <public-audio@w3.org>
You should be clearer about your repro steps, it took me a while to figure out what you meant. As far as I can tell you mean: Mash on the 'gate' button to play lots of notes at once (presumably this spins up multiple channels). Once the notes all stop playing the channels are now 'idle' and for some reason this maxes out the CPU (presumably trying to mix/synth all of them). In FF nightly all the CPU time is being spent somewhere inside your asm.js AOT compile (for some reason Firefox's sampling profiler does not track line number information for AOT compiles... I should file a bug about this.) It is interesting that the CPU usage steadily climbs over time in both FF and Chrome. Are you sure that this is just due to denormals? The fact that your demo is heavily minified and optimized makes it hard to tell what is actually going on in the code. It would be cool if your demonstration contained less code so it would be possible to look at the hydrogen IR (for v8) or the bytecode+generated jitcode (in spidermonkey). Those are usually my first steps when trying to understand exactly what's going wrong with JS perf, but I can't easily do either of those things on this demo. On Fri, Jun 20, 2014 at 5:21 AM, Stéphane Letz <letz@grame.fr> wrote: > To see the problem, here is a piano physical model in C++ compiled in asm.js using emcsripten. A single string is then duplicated (for "bug" demonstration purpose) 16 times, so 16 strings are computed all the time. > > http://faust.grame.fr/www/piano.html > > Chrome CPU here ==> 36 % > > Hit the "gate" button to play a same note on all 16 string, wait some seconds, CPU raise to 100% > > Same issue with Firefox and Safari WebKit. > > Stéphane Letz
Received on Monday, 23 June 2014 03:18:25 UTC