5 ms·

While the great sunspider battles will be great for the future, practically does this really matter? Does it really have any impact at all for an average user,

While the great sunspider battles will be great for the future, practically does this really matter? Does it really have any impact at all for an average user, where, I suspect, the up-front costs of JIT never actually pay themselves off. This isn't intended to be Luddism, and these improvements will benefit future apps, but so much is made about JavaScript performance (see the hoopla about JIT being disabled for embedded browsers on iOS), yet I seriously doubt it makes an ounce of difference in the real world, where the overwhelming majority of the performance limitations exist in the DOM.

leeoniya 14y ago
when it comes to complex web apps, it makes a huge difference. big data is coming to browsers in the form of massive typed Arrays from canvas and maybe soon, audio and video. We're talking about hotspots that get executed 10M+ times. These aren't your grandma's onclick handlers.
- corresation 14y ago
  when it comes to complex web apps, it makes a huge difference. Such as what? Give some examples. Further -- as a developer -- I cannot fathom "big data coming to browsers". This is racing tires on street cars: Theoretically useful, but of absolutely zero relevance for the overwhelming majority of users. Never has there been an actually practical benchmark of javascript engines and legitimate, real-world websites. Instead it's all nonsense like Sunspider. And don't misunderstand -- this actually can be a net negative for users because what benefits a 10M iteration loop is of negative consequence to an occasionally run event handler.
  - leeoniya 14y ago
    i'm doing interactive image analysis in canvas. i have pixel iteration/algo loops that easily hit 10M. my canvases are typically 1550x2006. mozilla also demoed js decoding H.264 video in realtime, the utility of which is of course questionable... the point is, though, that typed arrays are already a reality, and they are enormous. you can argue about how good an idea that was, but now that they're here, JITs are absolutely necessary.
    - corresation 14y ago
      Fun project, but how many users of your app are there? One, including you? Such "high intensity" apps see incredibly limited marketplace success because it generally isn't the ideal platform for them, and the marginal gains from JavaScript engine to JavaScript engine (without a major reboot like asm.js) makes them completely non-competitive to alternative platforms.
      - leeoniya 14y ago
        yes, it's an internal tool for several people at the moment. your characterization of "real-world websites" is somewhat misguided, I think. JITs, by design are targeted towards compute-heavy applications built for the web platform, not "typical" websites. so to say they will have little effect on websites is probably accurate, but misplaced. mozilla is building Firefox OS, where these JITs will play a critical role in smoothness of interaction and almost certainly fewer cpu cycles on mobile devices to save battery life.
      - fpgeek 14y ago
        Talk about goalpost-moving. First you ask for apps that benefit from these kinds of optimizations. Then someone gives you an example and you say it isn't important because it probably doesn't have many users? That's a catch-22. Apps like that can't have many users because the improvements they depend on aren't widely deployed. However, those improvements will never be widely deployed if people persuasively argue against their importance using evidence like a small user base...
        corresation 14y ago
        Goalpost-moving? You mean in my OP where I asked whether it benefits the average user? Where I said that the majority of performance issues remain in the DOM? I moved no goalpost. I am saying exactly what I always said. What the GP said that they are doing is almost certainly an ill-conceived project because JavaScript -- without a major change like asm.js -- simply cannot offer competitive performance as a facet of the language. Which is why we don't build a renderer in JavaScript, but instead layer it over WebGL, for instance.
  - ww520 14y ago
    I actually have an example not long ago. There are some long backend job processing that I want to display the status log, beyond just the progress bar. The log records are polled in via Ajax. When it got pretty big, like couple hundreds K, Chrome crawled to its knee, freezing hard. I thought it was the DOM updates but it was the Javascript code. Firefox has no problem. I ended up having to re-structure the feature to not showing the whole log.
    - aktau 14y ago
      The long log problem I experienced as well in Chrome, didn't know it was JS related though, I also assumed the DOM to be culpable!
      - ww520 14y ago
        I commented out the DOM update portion of the code and left just the Javascript code running. It still hung Chrome, so it's Javascript related, at least on Chrome's version of Javascript.
  - tbrownaw 14y ago
    Aren't people starting to use it for writing games now?
ww520 14y ago
Faster performance enables new types of applications - game, sound decoding/encoding, video rendering/encoding, phone apps, office apps, graphic apps, editors, etc. Also new JIT can be used in backend systems similar to Node where any performance bump helps.
- corresation 14y ago
  People have been saying this for well over a decade now. The performance impediment remains the DOM, just as it has always been. And where real benefits come to JavaScript engines, it is through the exposure of native code to the duct-tape of JavaScript: WebGL, SVG, the Media Capture APIs, CSS hardware transforms, and on and on. Where JavaScript is the thinnest veneer over native functionality.
  - ww520 14y ago
    For example, the game logic loop cannot be offloaded to the plug-ins. Simple path-finding is expensive; updating the physical properties of thousands or tens of thousands objects 60 fps is expensive. These kinds of game don't exist because Javascript is not fast enough.
    - ww520 14y ago
      I'll give you another example. That was one game I have in mind that involved simply pixels. 100x100 grid is 10K objects; 400x300 grid is 120K objects. 40fps x 120K is about 5M objects/second. Each object involves however so much processing. Doubling to 800x600 gives 20M objects/second. It adds up fast.
lambda 14y ago
Why do you doubt that it makes a difference in the real world? One of the things you need to remember is that in general, web app developers need to target yesterday's browser on yesterday's hardware. So they tend to be fairly conservative about the performance requirements. But as browsers and hardware improve, the benefits trickle down until suddenly, it's possible to do something that you never could do before. So sure, the average web app, which is designed to run on old versions of IE on outdate hardware, probably won't see much of an improvement to this. But cutting edge demos absolutely will. And when this version is the "old browser running on old hardware", general purpose web apps will absolutely be able to take advantage of these improvements and do things that would simply be unheard of beforehand.
- corresation 14y ago
  One of the things you need to remember I have been building and architecting very rich web applications before most caught onto this web thing. I was an original tester of XmlHttpRequest back when it was a safe-for-scripting ActiveX "abomination". I recently made a ridiculously full featured stop-motion recording studio -- in the browser -- for my children after they were enamored by something similar at the Science Centre. And JavaScript performance has not been -- remotely -- an issue for a long, long time. The facets that make these apps powerful are technologies like WebGL, Canvas, SVG, CSS, and so on. Things that I wouldn't imagine doing more than simple orchestrations in code. People use JavaScript performance on a completely artificial benchmark like Sunspider as a proxy for real-world browser performance. Yet it is at most a minor correlation, and has incredibly little to do with causation of a good experience. If you think I'm joking or overstating, turn off the JIT in your browser and use it for a day. Is your experience devastated? Can you even tell the difference?
  - kkowalczyk 14y ago
    There's a big difference between "my use case" and "all use cases". Sure, JavaScript is fast enough for a lot of things. But it's also too slow for many things that reasonable people would like to do on the web. See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin). pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time. pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins. Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful. We're still far away from making JS speed covering all the important use cases. Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.
pjscott 14y ago
JIT doesn't kick in until a part of the code has already become hot, as determined by watching it. That event handler that only gets run once in a while won't get JITted; it'll continue to be interpreted, ebcause it's not a hot spot.
ahoge 14y ago
>practically does this really matter? JavaScript is also a compiler target. Even smaller less heavy applications can benefit from these optimizations. >up-front costs of JIT You have to reach some threshold. The code is optimized as-needed.
kannanvijayan 14y ago
The Baseline JIT will have more of an impact on common web code than highly optimized JITs like Ion. Most web code executes for a few iterations, and runs for short periods of time. Baseline takes over from the interpreter far sooner than either Jaeger or Ion, and compiles far faster than either of them. Much more common web code will end up getting executed under the baseline jit than with the existing jits. I disagree with your sentiment that it does not make a difference in the real world. The real world is changing. The web now runs on devices which span an order of magnitude in processing power (from low end phones, to high-end workstations). Fast javascript has only been around for a few years or so. Ubiquitous connectivity (everybody connected to the internet all the time) has only just started happening. And full-fledged APIs to make the web a robust development platform (e.g. WebAudio, WebRTC, WebGL, etc.) have only recently come on the scene, or are still being solidified. I think we have yet to see the full potential of all of these technologies tapped. In a previous life I worked in bioinformatics, and worked on a web-application to allow scientists to invoke and visualize the results of analyses on their tissue samples. Web 2.0 was all the rage back in those days, and V8's optimized JS engine was announced AFTER we developed most of our app. If we had been able to assume that kind of performance at the beginning, our app would have pushed much more of the UI to the frontend. Instead of clunky static server-generated images, we would have built beautiful, dynamic client-side visualization engines. The last few years of progress in JS execution has opened the web up as a platform target for a large range of apps. And every inch we push that forward opens the door for a few more potential applications to reasonably be moved to the web. That's what it means to me, anyway. Push the line forward a few inches, and it means a few more features that somebody wasn't able to implement before, but are able to now. A few more apps that can target the web. That means more to some people and less to others. But I can say with certainty that it would have meant a lot to my prior bioinformatician self. And I'm sure there are developers like me, out there, who look at what JS can do, increasing day by day, and ask themselves "now what can I build with that?". I think it's a good thing to make the answer to that question as open ended as possible :)
- bradleyjg 14y ago
  Is there some particular reason to want every single application to run in a web browser?

leeoniya 14y ago

when it comes to complex web apps, it makes a huge difference. big data is coming to browsers in the form of massive typed Arrays from canvas and maybe soon, audio and video. We're talking about hotspots that get executed 10M+ times. These aren't your grandma's onclick handlers.

corresation 14y ago
when it comes to complex web apps, it makes a huge difference. Such as what? Give some examples. Further -- as a developer -- I cannot fathom "big data coming to browsers". This is racing tires on street cars: Theoretically useful, but of absolutely zero relevance for the overwhelming majority of users. Never has there been an actually practical benchmark of javascript engines and legitimate, real-world websites. Instead it's all nonsense like Sunspider. And don't misunderstand -- this actually can be a net negative for users because what benefits a 10M iteration loop is of negative consequence to an occasionally run event handler.
- leeoniya 14y ago
  i'm doing interactive image analysis in canvas. i have pixel iteration/algo loops that easily hit 10M. my canvases are typically 1550x2006. mozilla also demoed js decoding H.264 video in realtime, the utility of which is of course questionable... the point is, though, that typed arrays are already a reality, and they are enormous. you can argue about how good an idea that was, but now that they're here, JITs are absolutely necessary.
  - corresation 14y ago
    Fun project, but how many users of your app are there? One, including you? Such "high intensity" apps see incredibly limited marketplace success because it generally isn't the ideal platform for them, and the marginal gains from JavaScript engine to JavaScript engine (without a major reboot like asm.js) makes them completely non-competitive to alternative platforms.
    - leeoniya 14y ago
      yes, it's an internal tool for several people at the moment. your characterization of "real-world websites" is somewhat misguided, I think. JITs, by design are targeted towards compute-heavy applications built for the web platform, not "typical" websites. so to say they will have little effect on websites is probably accurate, but misplaced. mozilla is building Firefox OS, where these JITs will play a critical role in smoothness of interaction and almost certainly fewer cpu cycles on mobile devices to save battery life.
    - fpgeek 14y ago
      Talk about goalpost-moving. First you ask for apps that benefit from these kinds of optimizations. Then someone gives you an example and you say it isn't important because it probably doesn't have many users? That's a catch-22. Apps like that can't have many users because the improvements they depend on aren't widely deployed. However, those improvements will never be widely deployed if people persuasively argue against their importance using evidence like a small user base...
      - corresation 14y ago
        Goalpost-moving? You mean in my OP where I asked whether it benefits the average user? Where I said that the majority of performance issues remain in the DOM? I moved no goalpost. I am saying exactly what I always said. What the GP said that they are doing is almost certainly an ill-conceived project because JavaScript -- without a major change like asm.js -- simply cannot offer competitive performance as a facet of the language. Which is why we don't build a renderer in JavaScript, but instead layer it over WebGL, for instance.
- ww520 14y ago
  I actually have an example not long ago. There are some long backend job processing that I want to display the status log, beyond just the progress bar. The log records are polled in via Ajax. When it got pretty big, like couple hundreds K, Chrome crawled to its knee, freezing hard. I thought it was the DOM updates but it was the Javascript code. Firefox has no problem. I ended up having to re-structure the feature to not showing the whole log.
  - aktau 14y ago
    The long log problem I experienced as well in Chrome, didn't know it was JS related though, I also assumed the DOM to be culpable!
    - ww520 14y ago
      I commented out the DOM update portion of the code and left just the Javascript code running. It still hung Chrome, so it's Javascript related, at least on Chrome's version of Javascript.
- tbrownaw 14y ago
  Aren't people starting to use it for writing games now?

ww520 14y ago

Faster performance enables new types of applications - game, sound decoding/encoding, video rendering/encoding, phone apps, office apps, graphic apps, editors, etc. Also new JIT can be used in backend systems similar to Node where any performance bump helps.

corresation 14y ago
People have been saying this for well over a decade now. The performance impediment remains the DOM, just as it has always been. And where real benefits come to JavaScript engines, it is through the exposure of native code to the duct-tape of JavaScript: WebGL, SVG, the Media Capture APIs, CSS hardware transforms, and on and on. Where JavaScript is the thinnest veneer over native functionality.
- ww520 14y ago
  For example, the game logic loop cannot be offloaded to the plug-ins. Simple path-finding is expensive; updating the physical properties of thousands or tens of thousands objects 60 fps is expensive. These kinds of game don't exist because Javascript is not fast enough.
  - ww520 14y ago
    I'll give you another example. That was one game I have in mind that involved simply pixels. 100x100 grid is 10K objects; 400x300 grid is 120K objects. 40fps x 120K is about 5M objects/second. Each object involves however so much processing. Doubling to 800x600 gives 20M objects/second. It adds up fast.

lambda 14y ago

Why do you doubt that it makes a difference in the real world? One of the things you need to remember is that in general, web app developers need to target yesterday's browser on yesterday's hardware. So they tend to be fairly conservative about the performance requirements. But as browsers and hardware improve, the benefits trickle down until suddenly, it's possible to do something that you never could do before. So sure, the average web app, which is designed to run on old versions of IE on outdate hardware, probably won't see much of an improvement to this. But cutting edge demos absolutely will. And when this version is the "old browser running on old hardware", general purpose web apps will absolutely be able to take advantage of these improvements and do things that would simply be unheard of beforehand.

corresation 14y ago
One of the things you need to remember I have been building and architecting very rich web applications before most caught onto this web thing. I was an original tester of XmlHttpRequest back when it was a safe-for-scripting ActiveX "abomination". I recently made a ridiculously full featured stop-motion recording studio -- in the browser -- for my children after they were enamored by something similar at the Science Centre. And JavaScript performance has not been -- remotely -- an issue for a long, long time. The facets that make these apps powerful are technologies like WebGL, Canvas, SVG, CSS, and so on. Things that I wouldn't imagine doing more than simple orchestrations in code. People use JavaScript performance on a completely artificial benchmark like Sunspider as a proxy for real-world browser performance. Yet it is at most a minor correlation, and has incredibly little to do with causation of a good experience. If you think I'm joking or overstating, turn off the JIT in your browser and use it for a day. Is your experience devastated? Can you even tell the difference?
- kkowalczyk 14y ago
  There's a big difference between "my use case" and "all use cases". Sure, JavaScript is fast enough for a lot of things. But it's also too slow for many things that reasonable people would like to do on the web. See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin). pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time. pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins. Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful. We're still far away from making JS speed covering all the important use cases. Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.

pjscott 14y ago

JIT doesn't kick in until a part of the code has already become hot, as determined by watching it. That event handler that only gets run once in a while won't get JITted; it'll continue to be interpreted, ebcause it's not a hot spot.

ahoge 14y ago

>practically does this really matter? JavaScript is also a compiler target. Even smaller less heavy applications can benefit from these optimizations. >up-front costs of JIT You have to reach some threshold. The code is optimized as-needed.

kannanvijayan 14y ago

The Baseline JIT will have more of an impact on common web code than highly optimized JITs like Ion. Most web code executes for a few iterations, and runs for short periods of time. Baseline takes over from the interpreter far sooner than either Jaeger or Ion, and compiles far faster than either of them. Much more common web code will end up getting executed under the baseline jit than with the existing jits. I disagree with your sentiment that it does not make a difference in the real world. The real world is changing. The web now runs on devices which span an order of magnitude in processing power (from low end phones, to high-end workstations). Fast javascript has only been around for a few years or so. Ubiquitous connectivity (everybody connected to the internet all the time) has only just started happening. And full-fledged APIs to make the web a robust development platform (e.g. WebAudio, WebRTC, WebGL, etc.) have only recently come on the scene, or are still being solidified. I think we have yet to see the full potential of all of these technologies tapped. In a previous life I worked in bioinformatics, and worked on a web-application to allow scientists to invoke and visualize the results of analyses on their tissue samples. Web 2.0 was all the rage back in those days, and V8's optimized JS engine was announced AFTER we developed most of our app. If we had been able to assume that kind of performance at the beginning, our app would have pushed much more of the UI to the frontend. Instead of clunky static server-generated images, we would have built beautiful, dynamic client-side visualization engines. The last few years of progress in JS execution has opened the web up as a platform target for a large range of apps. And every inch we push that forward opens the door for a few more potential applications to reasonably be moved to the web. That's what it means to me, anyway. Push the line forward a few inches, and it means a few more features that somebody wasn't able to implement before, but are able to now. A few more apps that can target the web. That means more to some people and less to others. But I can say with certainty that it would have meant a lot to my prior bioinformatician self. And I'm sure there are developers like me, out there, who look at what JS can do, increasing day by day, and ask themselves "now what can I build with that?". I think it's a good thing to make the answer to that question as open ended as possible :)

bradleyjg 14y ago
Is there some particular reason to want every single application to run in a web browser?