Google revs Chrome's V8 JavaScript engine to drive high-performance web apps

Google revs Chrome's V8 JavaScript engine to drive high-performance web apps

Summary: Google aims to stamp out stuttering and dropped frames in complex web apps in Chrome by changing how the browser compiles JavaScript to native code.

TOPICS: Web development

Google has tweaked Chrome's JavaScript engine to boost the performance of web applications in the browser.

Read this

Do you save passwords in Chrome? Maybe you should reconsider

Do you save passwords in Chrome? Maybe you should reconsider

Every modern browser lets you save and sync user names and passwords for your favorite websites. Maybe that's not such a good idea.

Chrome's V8 JavaScript engine compiles JavaScript into machine code just before it is executed. Historically, V8 compiled JavaScript on the main thread, where it could interfere with the performance of the JavaScript application.

In the latest Chrome Beta release, Google has enabled concurrent compilation, which offloads an important part of the compilation process to a background thread to deliver better performance for web apps.

Where does the performance boost come from?

In a blogpost, Yang Guo, multi-threaded V8 engineer at Google, explained how the V8 engine compiles JavaScript in several phases.

The initial "compilation phase is fast but doesn't focus on optimising the code, just on getting it done quickly", Guo wrote.

However blocks of JavaScript code that are executed very often are compiled a second time, this time by an optimising compiler, which takes longer to complete than the initial compilation but that uses optimisation techniques to deliver faster code.

"Until now, V8 took turns compiling optimised Javascript code and executing it. For large pieces of code this could become a nuisance, and in complex applications like games it could even lead to stuttering and dropped frames," he wrote.

The switch to concurrent compilation tackles this issue, he said.

To demonstrate the performance increase concurrent compilation makes possible Google produced two graphs showing V8 performance when running Mandreel, part of the Octane 2.0 benchmark suite, on the Nexus 5 phone.

The first graph shows V8 running without concurrent compilation. V8 is fully occupied with optimising a large piece of code, causing an execution pause of more than 600ms.


Enabling concurrent compilation, allows the optimisation to take place in a background thread without pausing the application's execution, as seen below.


Concurrent compilation improved the Mandreel score of Octane 2.0 by 27 percent on a Nexus 5, Guo wrote, and made graphic-intensive applications such as the Epic Citadel Demo run even smoother in Chrome.

The concurrent compilation feature available in the Chrome Beta release will be added to the stable release of the browser at a later date.

Firefox will also move the entire just-in-time compilation process off the main thread in the forthcoming Firefox 29 release, currently available to test through its Aurora release channel.

More on Google Chrome

Topic: Web development


Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • another nail in M$ coffin!

    The FOSS is defeating the axis of evil software, step by step.
    LlNUX Geek
    • This article does not mention Microsoft

      and your comment is not topical.
    • IE has done JIT on a separate thread since IE9

      from last link: "Chakra was built to take advantage of two cores, with the second core compiling JavaScript down to native machine code to help speed up the browser."
      • Is that why IE9 was so amazingly fast?

        You *are* funny. Just because the product sucks doesn't mean they didn't get some parts right. Unfortunately, the millions of rotten design choices that makes it bad for the few good ones.

        I try not to hate. But IE has a special place in the hearts of most web / full-stack developers. A deep, dark, evil place where the bastard architects who put the designed the damn software have unspeakable, painful things done until they cry mercy and receive none ...

        Sorry, I'm back. Yeah, IE 9, not so good. But it is the first acceptable build of IE for cross browser development.

        Now don't get me started on IE 8...
    • Bad image

      People like you really paint a bad image of Linux and OSS enthusiasts. So much hate.
      Rann Xeroxx
  • Eh?

    I've never understood this obsession with how fast JS is. There are many more things that Chrome needs to work on that should be much more important than getting slightly faster JS speed. All browsers have fairly good JS rendering speed.
    Michael Alan Goff
    • Oh, I think it is appropriate to work on

      With the pressure on devs to speed up the development cycle of web apps, and their capability, large multiple libraries are being used (sites regularly drop in both angular.js and jQuery, just as a baseline.) The web would have slowed significantly the last couple of years if the major browser makers had not been spending so much time on faster JIT javascript compilation.
      • I guess that makes sense

        I just really wish they'd focus this much energy on the rest of their browser. We'd all benefit for it.
        Michael Alan Goff
    • Well, if anybody's serious about making games for it.

      "an execution pause of more than 600ms"

      If anybody's serious about making games using JavaScript, this is completely unacceptable. Most games need to run at least 30 frames/second, ideally more than 60. A freeze of over half a second is unacceptable.
      • Serious game makers

        Don't use JavaScript.
        Michael Alan Goff
        • For the reason I gave.

          For the reason I gave.
          • Better performance is good

            But it will never have native performance period.
            Michael Alan Goff
  • How many ways are there to disrupt conference among Chrome Browsers

    Google just reduced one possibility. Find two more and speed will increase by twofold.
  • Show some Mozillove, ZDNet!!!

    Big article touting concurrent compilation in Chrome V8...and then the last two lines mention as a side note that oh, and it's coming in FireFox 29 too, already available as alpha on the aurora build.

    How about an article with a title like "Mozilla FireFox revs JavaScript engine...etc." Oh, right...GOOG has the money.
  • Make Flash stop craashing would be great!!

    My biggest issue is that Chrome crashes a lot at Flash site like etc. If they could get together with adpbe and fix that it would be great.