4 ms·

I've been watching a bunch of this JS performance stuff unfold over the past few months (including that huge rant a while ago). People lament the lack of JITing

I've been watching a bunch of this JS performance stuff unfold over the past few months (including that huge rant a while ago). People lament the lack of JITing in UIWebView or that JS is inherently slow or whatever but if you're targeting mobile, there's usually only one thing that matters: Can your JS rendering code consistently execute within 16ms? JS (even without JIT) is certainly fast enough to do this if you offload anything intensive to workers (in fact, I recommend that you put your whole app except for the real time aspects in a worker if possible) and schedule long running tasks over several requestAnimationFrames. Usually the only issue is that GC pauses can cause hiccups > 16ms and you're in no control of that. This has traditionally been seen as a deal-breaker. That's why I'm excited about Asm.js (and LLJS) -- even on generic JS runtimes, it's my understanding they don't generate garbage, and can execute without GC pauses. So I'm looking forward to writing most of my app in traditional JS in a worker, and the realtime components in Asm.js.

munificent 13y ago
> if you're targeting mobile, there's usually only one thing that matters: There are two things that matter, actually: 1. How quickly can you get your app up and running and responding to user input? 2. Once that's done, can you continue to maintain 60 fps?
- peterhunt 13y ago
  Good point. I was mostly responding to common criticisms. I think JS boot time is usually pretty good since it's easy to incrementally load code in.
  - lukifer 13y ago
    It's not just about loading the JS; it's about loading the entire WebView, or whatever other environment. (Obviously, this is an issue that every application faces, it's just something worth paying attention to.)
modeless 13y ago
GC pauses are not the only issue. Image loading often introduces longer pauses than GC, and input latency is a huge problem too. I've written a benchmark that exposes these responsiveness issues: http://google.github.io/latency-benchmark http://google.github.io/latency-benchmark
- peterhunt 13y ago
  Yeah jpeg decoding is a big one, but I think it's less to do with raw performance and more to do with the fact that there aren't any hooks to help you control the user experience around it (i.e. there is no way to determine if you're done decoding unless you write the decoder yourself and draw to canvas, which increases your latency by a lot). IIRC I think dropped frames from jpeg decoding is less of an issue in today's webkit, but I'm not sure. I seem to remember there being workarounds like adding a no-op CSS animation or iframe to coax the browser to do it off of the UI thread. That's a nice demo you have there, btw, I'll have to check it out more.
  - modeless 13y ago
    Thanks! JPEG decoding isn't the only problem with image loading. Image resizing, texture upload, and relayout/painting related to image loading all contribute to jank. Also, as you pointed out, the fact that it's impossible to schedule any of those things at appropriate times because you have no control over or visibility about when they happen.
    - peterhunt 13y ago
      Are there relayout issues I'm not aware of with images when you're using absolute positioning? I did some experiments a while ago with running jpgjs in a webworker and was able to get zero-jank images by splitting the copy to canvas across multiple requestAnimationFrames. However it adds a significant amount of latency and I'm not sure it's worth the trade off. I am wondering, though, if one built a pipelined progressive jpeg downloaded/decoder/renderer with this technique if it would yield positive results.
general_failure 13y ago
asm.js is a way to write javascript to help the JIT. It's intended to be autogenerated by tools. It has nothing to do with GC. asm.js will accumulate garbage just like normal javascript.
- peterhunt 13y ago
  I don't think that's correct, since I believe asm.js manages its own heap via a big typed array and does not allocate anything tracked by the runtime GC (at least that's what LLJS does and I believe that asm.js does the same thing)
  - v413 13y ago
    No. asm.js is simply a subset of javascript. That is all. Here is the actual spec: http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/ The creation of big typed array simulating a memory pool is a construction of Emscripten. asm.js in that context is simply the vehicle / language.
    - peterhunt 13y ago
      Hmm perhaps it's not part of the spec, but I believe all languages that compile down to it do this. And the spec mentions "absence of garbage collection" so I believe you're at the very least strongly encouraged to avoid it (if not forbidden -- does OdinMonkey even have a GC?)
  - deleted 13y ago
    [deleted]
- spyder 13y ago
  There is no garbage in asm.js: "The asm.js model provides a model closer to C/C++ by eliminating dynamic type guards, boxed values, and garbage collection." From the asm.js FAQ (http://asmjs.org/faq.html http://asmjs.org/faq.html)

munificent 13y ago

> if you're targeting mobile, there's usually only one thing that matters: There are two things that matter, actually: 1. How quickly can you get your app up and running and responding to user input? 2. Once that's done, can you continue to maintain 60 fps?

peterhunt 13y ago
Good point. I was mostly responding to common criticisms. I think JS boot time is usually pretty good since it's easy to incrementally load code in.
- lukifer 13y ago
  It's not just about loading the JS; it's about loading the entire WebView, or whatever other environment. (Obviously, this is an issue that every application faces, it's just something worth paying attention to.)

modeless 13y ago

GC pauses are not the only issue. Image loading often introduces longer pauses than GC, and input latency is a huge problem too. I've written a benchmark that exposes these responsiveness issues: http://google.github.io/latency-benchmark http://google.github.io/latency-benchmark

peterhunt 13y ago
Yeah jpeg decoding is a big one, but I think it's less to do with raw performance and more to do with the fact that there aren't any hooks to help you control the user experience around it (i.e. there is no way to determine if you're done decoding unless you write the decoder yourself and draw to canvas, which increases your latency by a lot). IIRC I think dropped frames from jpeg decoding is less of an issue in today's webkit, but I'm not sure. I seem to remember there being workarounds like adding a no-op CSS animation or iframe to coax the browser to do it off of the UI thread. That's a nice demo you have there, btw, I'll have to check it out more.
- modeless 13y ago
  Thanks! JPEG decoding isn't the only problem with image loading. Image resizing, texture upload, and relayout/painting related to image loading all contribute to jank. Also, as you pointed out, the fact that it's impossible to schedule any of those things at appropriate times because you have no control over or visibility about when they happen.
  - peterhunt 13y ago
    Are there relayout issues I'm not aware of with images when you're using absolute positioning? I did some experiments a while ago with running jpgjs in a webworker and was able to get zero-jank images by splitting the copy to canvas across multiple requestAnimationFrames. However it adds a significant amount of latency and I'm not sure it's worth the trade off. I am wondering, though, if one built a pipelined progressive jpeg downloaded/decoder/renderer with this technique if it would yield positive results.

general_failure 13y ago

asm.js is a way to write javascript to help the JIT. It's intended to be autogenerated by tools. It has nothing to do with GC. asm.js will accumulate garbage just like normal javascript.

peterhunt 13y ago
I don't think that's correct, since I believe asm.js manages its own heap via a big typed array and does not allocate anything tracked by the runtime GC (at least that's what LLJS does and I believe that asm.js does the same thing)
- v413 13y ago
  No. asm.js is simply a subset of javascript. That is all. Here is the actual spec: http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/ The creation of big typed array simulating a memory pool is a construction of Emscripten. asm.js in that context is simply the vehicle / language.
  - peterhunt 13y ago
    Hmm perhaps it's not part of the spec, but I believe all languages that compile down to it do this. And the spec mentions "absence of garbage collection" so I believe you're at the very least strongly encouraged to avoid it (if not forbidden -- does OdinMonkey even have a GC?)
- deleted 13y ago
  [deleted]
spyder 13y ago
There is no garbage in asm.js: "The asm.js model provides a model closer to C/C++ by eliminating dynamic type guards, boxed values, and garbage collection." From the asm.js FAQ (http://asmjs.org/faq.html http://asmjs.org/faq.html)