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/

• Category

  Science & Technology

[James Newton]

Actual talk starts at 10:00... before that it's fluff.

[hdzsound]

to me correcting a bug (out bound) is not code optimization ...

[Vít Novotný]

It's not a bug, it's a feature. Javascript, unlike C++ but much like other scripting languages, was always intended for the speed of development rather than execution.

[J Parril]

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.

[hdzsound]

Out of bound array access (read/write) is bad and the final result is unexpected.

V8 is not JavaScript so out of bound can result in others malfunction in other JS engine.

This was a simple example of a bug (not an optimization) the result here is hopefully only a slow loop.

But the result could be most worst, memory leak, heap memory corruption, etc. now, anything can happen.

[J Parril]

But it's not a bug. If the code is correct javascript, but slow javascript, that is not definable as a bug.

[J Parril]

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.

[alexgrinkov]

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...

[lennyhome]

Now opening popups even faster with JavaScript!

[Jon47]

Really awesome talk, thank you!