3 ms·

"XYZ isn't slow if run on a fast enough processor" is an utterly useless statement. My personal gripe with the eShop is the horrible startup time (compare to t

"XYZ isn't slow if run on a fast enough processor" is an utterly useless statement. My personal gripe with the eShop is the horrible startup time (compare to the time it takes the settings application to open - part of this can be assigned to it being a web application indeed), lack of partial/incremental presentation, and possibly lack of prefetching. Asset loading causing bad UX is always a frontend problem.

falcolas 6y ago
Any interpreted language is going to its performance/memory barriers long before a compiled language as the CPU and memory shrink. It's inevitable; the interpretation is an unavoidable overhead. Sure, you can write slow code in any language, but the language will limit how fast your code can ever be. This from a Python fanboi, FWIW. I'd never try and use Python on an embedded device where performance matters, not only for UI responsiveness, but for battery life.
- colejohnson66 6y ago
  V8 and SpiderMonkey use JIT compilation, not interpretation
  - arghwhat 6y ago
    V8 and SpiderMonkey extensively interpret, before functions are marked hot and traced, and every time they are deoptimized from failed guards.
    - imtringued 6y ago
      That only influences start up time.
      - arghwhat 6y ago
        No, it affects warm-up, which is not the same. JS is only JIT'ed if the interpreter decides that it has been running code enough for it to make sense, and then not even permanently. Some things will never JIT. Some things will JIT much later, leading to sudden CPU spikes later. And importantly, code will often deoptimize a few times, meaning that it drops back to interpreted to re-trace even if it had already optimized this code block. And as most web "applications" are loaded only to be thrown away as you finished reading fixed text, all of those resources were burnt for nothing. This includes an application like the eShop, which has limited need for JS for anything other than lightweight asset handling.

falcolas 6y ago

Any interpreted language is going to its performance/memory barriers long before a compiled language as the CPU and memory shrink. It's inevitable; the interpretation is an unavoidable overhead. Sure, you can write slow code in any language, but the language will limit how fast your code can ever be. This from a Python fanboi, FWIW. I'd never try and use Python on an embedded device where performance matters, not only for UI responsiveness, but for battery life.

colejohnson66 6y ago
V8 and SpiderMonkey use JIT compilation, not interpretation
- arghwhat 6y ago
  V8 and SpiderMonkey extensively interpret, before functions are marked hot and traced, and every time they are deoptimized from failed guards.
  - imtringued 6y ago
    That only influences start up time.
    - arghwhat 6y ago
      No, it affects warm-up, which is not the same. JS is only JIT'ed if the interpreter decides that it has been running code enough for it to make sense, and then not even permanently. Some things will never JIT. Some things will JIT much later, leading to sudden CPU spikes later. And importantly, code will often deoptimize a few times, meaning that it drops back to interpreted to re-trace even if it had already optimized this code block. And as most web "applications" are loaded only to be thrown away as you finished reading fixed text, all of those resources were burnt for nothing. This includes an application like the eShop, which has limited need for JS for anything other than lightweight asset handling.