D4mations.com

Google I/O 2012 – Breaking the JavaScript Speed Limit with V8



Daniel Clifford

Are you are interested in making JavaScript run blazingly fast in Chrome? This talk takes a look under the hood in V8 to help you identify how to optimize your JavaScript code. We’ll show you how to leverage V8’s sampling profiler to eliminate performance bottlenecks and optimize JavaScript programs, and we’ll expose how V8 uses hidden classes and runtime type feedback to generate efficient JIT code.

Attendees will leave the session with solid optimization guidelines for their JavaScript app and a good understanding on how to best use performance tools and JavaScript idioms to maximize the performance of their application with V8.

For all I/O 2012 sessions, go to https://developers.google.com/io/

Original source

d4mer

, , ,

37 responses to “Google I/O 2012 – Breaking the JavaScript Speed Limit with V8”

  4. In my opinion, this really shows how bad JavaScript is as a programming language. People been complaining for ages how easy it is to shoot yourself in the foot with C++, but it seems to me that JS is even worse in this regard. I wish the language itself was progressing with the same speed as JS engines.

  10. The *actual* point is that something that would be a crash error (or something more disastrous) in another language may simply result in allocation/conversion costs in JavaScript. At the *language level*, JS doesn't *have* arrays as they are normally constructed; the creation of arrays (as opposed to dictionaries) is a JIT/run-time optimization (and there are still no hard bounds). There is no "out of bounds", there is only accessing unassigned members.

  14. That's fair. He probably should have used an example that wasn't such an obvious mistake. But to say v8 isn't javascript is a little harsh, javascript isn't v8, and v8 does things differently than most engines, but they're smart enough to avoid memory leaks when using outbound locations in an array. I think he actually mentioned growing large arrays as the correct convention.

  16. This is a big problem to developers. The reason you haven't seen a change in performance is because the browsers don't do anything that requires performance to run. If a webpage pauses for a noticeable amount of time in IE6 than that web page is broken. The goal here is not to have performance which is noticeable to guys like you, who don't do anything interesting with a browser. It's to make interesting things possible. In the mean time, you can enjoy the spell check, firewall, and advanced UI.

  17. As a user I haven't experienced any change. Sites from today feel pretty much like before the whole JS ending war started. The speed gains are marginal outside synthetic tests unless you try to play a JavaScript port of Quake in the browser…

  21. zval under the hood is just a tagged union. tagged pointers (like V8 does it) or NaN-tagging (used by SpiderMonkey, JavaScriptCore) are compact ways to represent tagged unions. they allow to reduce memory footprint and make passing tagged values around faster e.g. tagged pointer will occupy one machine word and can be stored in a single machine register while zval would require several registers.

  27. Great talk. Seems like the JS code is actually calculating the 24999th prime? You insert 1 into the array too that's why iterating from index 1 instead of 0 works. The example seems a little bit contrived – the codie isn't terribly great to begin with.

  28. so to clarify, i think this is just one of those cases where people think "working on performance is fun and interesting, now i just need to utter some phrases to justify it". don't get me wrong, i agree the performance stuff can be fun and useful, but you can't really provide a general (in scope) rational justification without sounding hollow.

  29. 2:15 performance matters because "every cycle that you win back when you do performance optimisation you can invest in something new that you haven't been able to do before". what a hollow marketing phrase. "every cycle"? = clockcycle? if the goal is to do new things you haven't been able to do before, I would say first figure out what's required to allow you to do the new thing, usually it's actually writing the code for the new thing

  32. JavaScript engines share some design decisions so most of them suffer from the same things. If you try this example in FF/Safari you will see that performance improves there as well. In C++ you can read out-of-bounds, whether you get an error or not depends only on a memory layout. In this particular case you never actually read out of bounds, you just read an uninitialized part of an array. And C++ actually does the same (even worse: prime_count is uninitialized).

  33. example demonstrates two very important things: corner cases that V8 does not like (out-of-bounds reads, arithmetic with undefined value) and a technique that can be universally applied to optimize virtually any JavaScript code.

Leave a Reply