On Saturday, December 13, 2014 5:47:11 PM UTC-8, smaug wrote: > On 12/14/2014 02:25 AM, jwmerr...@gmail.com wrote: > > I have recently been working on making it possible to achieve 60 fps > > animations in Elm (a compile-to-js functional language http://elm-lang.org/) > > programs backed by canvas. > > > > I posted about progress and limitations on the Elm list > > > > https://groups.google.com/forum/#!topic/elm-discuss/ErEx6IZNNAQ > > > > and I thought some of the material might be interesting to the Mozilla JS > > implementers. > > > > Summarizing the relevant parts: > > > > 1. Elm produces kind of a lot of garbage. This seems to make it impossible > > to animate even simple scenes reliably at 60 fps in Firefox, but Chrome > > is doing a pretty good job. > > > > 2. You can compare the performance of my sample Elm program across browsers > > here: http://jsbin.com/cusahisozo > > > > 3. I also made a stripped down pure JS canvas animation and garbage > > collection benchmark. It has the advantage of having simple JS source code > > and > > tunable parameters that determine the rate of garbage allocation, but its > > disadvantage is that the garbage load is totally artificial, and might > > not be a good model for real programs. You can try it here (click "run with > > js" in the top right if it doesn't auto run): > > > > http://jsbin.com/puzojazapi/1/edit?js,output > > > > If you're interested, please see the description of the benchmark and a > > summary of my findings in the post on the Elm list linked above. I'll > > refrain from reproducing it all here. My overall conclusion is that Chrome > > seems to have significantly lower maximum GC pauses for this workload. > > > > 4. Thanks for adding Timeline to the dev tools. It's totally sweet! > > > > I can see that there is and has been a lot of hard work on improving the > > Firefox GC. I spent some time perusing open issues, and I read Nicholas > > Nethercote's post about Generational GC landing earlier this year > > https://blog.mozilla.org/nnethercote/2014/03/31/generational-gc-has-landed/. > > Anyway, my point is that I'm not trying to troll the Mozilla folks about > > the v8 GC being ahead along some axis--I just wanted to report a case > > study that might be a useful data point. > > > > Is there anything here that I should open a ticket about? > > > > > Please file a bug and attach a testcase. > > Looks like your testcase creates tons of garbage, given that it ends up > triggering TOO_MUCH_MALLOC GC all the time. Looks very unusual to me. > I see ~30ms GCs (and 1-2ms CCs occasionally)
Which test case produces this message? The "artificial" one that is made in pure js (gray circles), or the "real" one that is the output of the Elm compiler (orange circles on a red background)? How would I find this out myself? > Any idea why Elm is so super garbage heavy? > Sounds like it needs some optimizations. I don't know how to quantify "super garbage heavy" yet. If you work really really hard, you can avoid per-frame allocation completely. But Elm definitely doesn't try to do that: at the very least, it creates a completely new internal representation of the "scene" on every frame. It seems like there's plenty of room to optimize Elm, but I also think it will help everyone who tries to do animation/games on the web if the browser GCs can be improved and tuned to minimize maximum latency where possible. > -Olli _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
