Background Javascript Compilation Boosts Chrome Performance

kc123 writes "The latest version of Chrome includes improvements in JavaScript compilation, according to the Chromium blog. Historically, Chrome compiled JavaScript on the main thread, where it could interfere with the performance of the JavaScript application. 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. In the latest Chrome Beta they've enabled concurrent compilation, which offloads a large part of the optimizing compilation phase to a background thread. The result is that JavaScript applications remain responsive and performance gets a boost."

Comments

Performance

[Sperbels]

Why would you be dynamically loading new code in the middle of a game loop anyway? You would have know this causes issues when you designed the application and would have loaded it all up prior to executing the loop.

Re:Performance

[Darktan]

Nope. That's the Just In Time part of the JIT. Javascript can't be (efficiently) compiled to native code until the data types of function arguments are know. Since Javascript is a dynamic language, the types can't be known until the function is actually called.

Re:Performance

[dshk]

No, JavaScript is not compiled before execution, because that would delay startup. It starts in interpreted mode. Then the runtime environment gradually compiles frequently running code. I do not know how advanced are the JavaScript runners, but the Java JIT compiler can even compile the same code fragment several times, using different optimizations as it collects more runtime statistics.

Re:Performance

[Threni]

> the Java JIT compiler can even compile the same code fragment several times, using different optimizations as
> it collects more runtime statistics.

Yes, it can start off optimized for grabbing VISA credit card numbers, but if it notices more Mastercards coming through the keylogger it can adapt accordingly.

Re:Performance

[TheRaven64]

JavaScript is quite different in its use from most languages that live in VMs. Java or .NET applications, for example, tend to be quite long-lived and often CPU dependent, so spending a couple of seconds at the start optimising them can be a big win. The VM will then build some profiling data and recompile things based on that, and may do some other tricks.

With JavaScript, in most cases, the thing that users care the most about is load time. It's often better to use a simple AST interpreter for JavaScript than a clever compiler, because you can start executing the interpreter as soon as you've got the text. If you spend more than a few ms getting the JS ready to run, users notice even if the resulting code is faster.

The 'often' is the important bit here, because some pages use JavaScript extensively for animations, games, and so on. In this case, users will notice if it's slow. They'll also notice if it's eating all of the CPU on their mobile device and flattening the battery. It's better in this case to switch to an optimised compiled representation as soon as possible, because you can get away with running the game slowly for a few second (while it's typically loading assets and displaying splash screens anyway), but after that people notice.

In both cases, after a while you've got some useful profiling data and so you want to recompile and generate more optimised code (unless it's just doing menu animations and the JavaScript is using 1% of your CPU, in which case the compiler is likely to consume more CPU time than the compiled code will save). Ideally, you want to do this in the background, on another core (or, at least, on a lower-priority thread on the same core), because otherwise you're interrupting the thing that the user cares about to run the compiler.

Re:This is worth a Slashdot article?

[sunderland56]

The "news for nerds" takeaway is: everyone is assuming mutiple-core systems now. For a single-core system, this will make things *slower*.

Re:This is worth a Slashdot article?

[poetmatt]

There are still single core systems that aren't legacy and use java?

Re:This is worth a Slashdot article?

[viperidaenz]

It might make things slower, but it still might make things *appear* faster but reducing pauses in the Javascript thread. You might not notice 10 10ms pauses but you'll probably notice a 100ms pause.

Re:It doesn't already do this?

[Anonymous Coward]

As far as I know Firefox already has this feature, and Internet Explorer had it even longer than that. Chrome is no longer the leading web browser, this is a nice illustration of that.

Re:This is worth a Slashdot article?

[viperidaenz]

What's Java got to do with anything in this article? Except Java and Javascript share common letters in their name.

Re:Call me...

[dshk]

We have the same performance critical application in both Java and Javascript. After doing many optimizations in JavaScript (and therefore running into several JavaScript JIT compiler bugs in different browser versions!), JavaScript is still much slower. JS is indeed a promise, but only because it is in newborn state if we consider using it for larger applications.

It is not an accident that Google tries to replace JavaScript with Dart, which already outperforms JavaScript and is more suitable for larger applications. JavaScript was never intended for such purpose. It is very good however, for scripting a web page.

The first rule of UI Thread.

[Kaenneth]

Do not block the UI thread.

Re:This is worth a Slashdot article?

[wonkey_monkey]

For a single-core system, this will make things *slower*.

Unless Chrome checks how many cores/threads are available and acts accordingly.

Re:It doesn't already do this?

[Tailhook]

Is anyone else surprised...?

I sure am. I mean these browsers are so expensive you'd think they'd optimize them for something other than making 8-10 levels of recursive <iframes> work so well for advertiser CDNs. I pay a lot of money for my Chrome license, just like you, and I expect more for my money than just a banner ad pump.

Re:Google Invents Multithreading

[Virtucon]

How stupid! The concept of multi-threading has been around since the 1950s.

Every day now I'm still amazed at how little newer members of the technology community actually know about the history, at least some concept, of where modern computing originated.

Re:This is worth a Slashdot article?

[thegarbz]

Multi-core systems have been the norm for consumers for what, 5 years now? Probably longer. One of the biggest complaints about the multi-core trend is that software isn't written to take advantage of it.

So I give you the following food for thought:
- Consumers who care about speed are unlikely to have a 10 year old computer.
- Consumers who have a 10 year old computer are unlikely to complain about the overhead multi-threading has on a single core computer.

Re:Still uses more CPU than IE/FF

[thegarbz]

I call bullshit. Just tested this myself:

Chrome Experiments on a CPU intensive page with half screen filled: 23% CPU
Firefox on the same page: 49% CPU

Chrome playing a 1080p Youtube Video: 7% CPU
Firefox playing a 1080p Youtube Video: 3% CPU, Flash plugin for Firefox 8% CPU

In both cases the GPU load appeared identical. Firefox v26, Chrome v32. I don't have IE10 or the flash player plugin for IE9 so it couldn't be tested.

Re:Too Late

[Lennie]

So it can automatically install updates (the service has more permissions than the user, so it can write to the program files directory).

I believe Firefox does it too (obviously it only has one service. I have seen Chrome set up multiple things (service and scheduled tasks) in multiple places, it's kinda crazy).