3 ms·

(Hi Geoffrey, ltns! :) ) The execution of the code, be it javascript on some modern engine or Java/Dalvik bytecode - that isn't typically the performance bottl

(Hi Geoffrey, ltns! :) ) The execution of the code, be it javascript on some modern engine or Java/Dalvik bytecode - that isn't typically the performance bottleneck. It is fast enough now. I'm not an expert on this (this is where I thread on thin ice), but my understanding is that the HTML/CSS logdoc/layout tree model is inherently non-performant compared to a more traditional hierarchical windowed object oriented model. It is too easy to write HTML/CSS that is not performant (it's way too easy to accidentally cause performance issues), while it is a lot more natural to write performant windowing/OO code. And inversely, harder to write code that is not performant.

gsnedders 11y ago
(Hi. :)) It depends a lot on what you're doing, and how much data you're processing. If we go by the premise that you're processing more data locally than you would in a web app (because you don't need to worry about the latency and you don't have a server to do the pre-processing and filtering of the data before it reaches the client), then actual VM performance is more significant. The last time I looked at any profiles of browsers on Gmail or FB, JIT'd code actually accounts for several of the most expensive functions (and you will notice if you disable the JIT). JS performance does matter—even if DOM performance dominates in the case of the common website (and note that Mozilla has actually been doing quite a lot of interesting work around teaching the JS VM more about the DOM, including rewriting parts in JS, which allows JIT optimisation to happen). It's definitely true that it's easier to write non-performant code using HTML/CSS (and <canvas> and WebGL don't really help here—because it's hard to ensure data gets correctly passed to accessibility layers), but I think that the majority of mobile apps are simple enough for it to not be a concern.
- johansch 11y ago
  I haven't done profiling of firefox os on a crappy device... but my suspicion is that it really is as simple as: even really-well-optimized html/css/js that needs to go through a browser core will suffer performance-wise compared to something with 10-15 less layers of indirection. (Like a traditional windowing toolkit.) The Android UI toolkit isn't exactly efficent (ha!), but still seems to beat Firefox OS on super-low-end hardware judging from the reviews I have seen. The internal windowing toolkit and java-like mini language with a VM that we made for Opera Mini 5/Opera Mobile 10 with both J2ME and C VM implementations was like 3x faster than the Android UI toolkit with Dalvik for typical windowing tasks. Without any super-fancy optimizations...
  - pcwalton 11y ago
    The indirection is a problem with existing browser implementations (and some spec issues, such as lack of Typed CSSOM, which is the current subject of work in the WGs). There is no fundamental reason that I can see as to why there needs to be a gap between the hardware and the graphics and layout of Web apps.
    - johansch 11y ago
      That sounds intriguing. But.. how?
      - pcwalton 11y ago
        Look at Servo and WebRender (disclaimer: I work on both), or just read "Fast and Parallel Webpage Layout", Meyerovich 2010 for much of it :)
  - jgraham 11y ago
    As a practical matter, my experience of using FirefoxOS everyday is that performance is not the main issue. Of course it could undoubtedly be improved, but it's acceptable, particularly once you put it onto reasonable hardware (i.e. not the $40 phones). Much more problematic is the lack of "premium content" i.e. services that — even if they are basically just webapps — don't work except on Android/iOS. This is a particularly vicious cycle; it's hard to convince anyone to put in the effort to support minority platforms, and it's hard to get users unless you support the same content as other platforms (see also: Windows Phone, which by all accounts is an excellent product that almost no one uses). There's also the fact that FirefoxOS is some years behind the other platforms in terms of developers and the competition has ~infinite resources, which means that some parts are lagging behind feature wise. Having said all of that, I don't think that Opera is a bad analog for the difficulties FirefoxOS faces, only it's not Opera Platform specifically but Presto in general. It had the same kind of issues with limited support from content creators and relatively available resources.
pcwalton 11y ago
CSS isn't less efficient than a traditional windowing model. In fact, its declarative nature is a big help when adopting legacy content to modern architectures. The "WM_PAINT/C++ code that calls GDI" model is not easy to adapt to multicore and GPUs. This is not to say that the browsers of today are optimally architected, of course. (In fact, I think they're quite suboptimally architected for 2015 hardware. The "it's too easy to fall off the fast paths" problem of HTML/CSS is a symptom of legacy browser architecture, not a problem with the layout/styling model.)

gsnedders 11y ago

(Hi. :)) It depends a lot on what you're doing, and how much data you're processing. If we go by the premise that you're processing more data locally than you would in a web app (because you don't need to worry about the latency and you don't have a server to do the pre-processing and filtering of the data before it reaches the client), then actual VM performance is more significant. The last time I looked at any profiles of browsers on Gmail or FB, JIT'd code actually accounts for several of the most expensive functions (and you will notice if you disable the JIT). JS performance does matter—even if DOM performance dominates in the case of the common website (and note that Mozilla has actually been doing quite a lot of interesting work around teaching the JS VM more about the DOM, including rewriting parts in JS, which allows JIT optimisation to happen). It's definitely true that it's easier to write non-performant code using HTML/CSS (and <canvas> and WebGL don't really help here—because it's hard to ensure data gets correctly passed to accessibility layers), but I think that the majority of mobile apps are simple enough for it to not be a concern.

johansch 11y ago
I haven't done profiling of firefox os on a crappy device... but my suspicion is that it really is as simple as: even really-well-optimized html/css/js that needs to go through a browser core will suffer performance-wise compared to something with 10-15 less layers of indirection. (Like a traditional windowing toolkit.) The Android UI toolkit isn't exactly efficent (ha!), but still seems to beat Firefox OS on super-low-end hardware judging from the reviews I have seen. The internal windowing toolkit and java-like mini language with a VM that we made for Opera Mini 5/Opera Mobile 10 with both J2ME and C VM implementations was like 3x faster than the Android UI toolkit with Dalvik for typical windowing tasks. Without any super-fancy optimizations...
- pcwalton 11y ago
  The indirection is a problem with existing browser implementations (and some spec issues, such as lack of Typed CSSOM, which is the current subject of work in the WGs). There is no fundamental reason that I can see as to why there needs to be a gap between the hardware and the graphics and layout of Web apps.
  - johansch 11y ago
    That sounds intriguing. But.. how?
    - pcwalton 11y ago
      Look at Servo and WebRender (disclaimer: I work on both), or just read "Fast and Parallel Webpage Layout", Meyerovich 2010 for much of it :)
- jgraham 11y ago
  As a practical matter, my experience of using FirefoxOS everyday is that performance is not the main issue. Of course it could undoubtedly be improved, but it's acceptable, particularly once you put it onto reasonable hardware (i.e. not the $40 phones). Much more problematic is the lack of "premium content" i.e. services that — even if they are basically just webapps — don't work except on Android/iOS. This is a particularly vicious cycle; it's hard to convince anyone to put in the effort to support minority platforms, and it's hard to get users unless you support the same content as other platforms (see also: Windows Phone, which by all accounts is an excellent product that almost no one uses). There's also the fact that FirefoxOS is some years behind the other platforms in terms of developers and the competition has ~infinite resources, which means that some parts are lagging behind feature wise. Having said all of that, I don't think that Opera is a bad analog for the difficulties FirefoxOS faces, only it's not Opera Platform specifically but Presto in general. It had the same kind of issues with limited support from content creators and relatively available resources.

pcwalton 11y ago

CSS isn't less efficient than a traditional windowing model. In fact, its declarative nature is a big help when adopting legacy content to modern architectures. The "WM_PAINT/C++ code that calls GDI" model is not easy to adapt to multicore and GPUs. This is not to say that the browsers of today are optimally architected, of course. (In fact, I think they're quite suboptimally architected for 2015 hardware. The "it's too easy to fall off the fast paths" problem of HTML/CSS is a symptom of legacy browser architecture, not a problem with the layout/styling model.)