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

[dshk]

It does not count when you load the code. What it does count is when it gets (Just in Time) compiled.

Re:Performance

[Sperbels]

Is it not compiled as soon it browser receives it?

Re:Performance

[Anonymous Coward]

It is, but is is done using a non-optimizing compiler to get it going quickly. A second pass is then ran through an optimizing compiler for commonly use segments.

If you had read the fine article you would have known that.

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

[Anonymous Coward]

Is it not compiled as soon it browser receives it?

Obviously it is not. JIT does not mean "javac" in disguise. JIT can be used to optimize runtime performance of a loop as it is executing, something a static compiler never does.

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

[lucm]

What is the point of reading the article when other people can do it instead and answer questions for stuff that is not obvious in the summary?

You must be one of the 53%.

Re:Performance

[khellendros1984]

That, and we're talking about Javascript; javac doesn't ever enter into the picture. It's equally true and equally relevant to say that JIT does not mean "python" or "g++" in disguise.

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:Performance

[bondsbw]

Because the game's UI is a Javascript textbox?

Duh.

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

It doesn't already do this?

[RobertJ1729]

Is anyone else surprised that it doesn't already do this? Do the other browsers not do this either?

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: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: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:Still uses more CPU than IE/FF

[Anonymous Coward]

Solution : Unplug fan cable.

Gooby Pls!

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.

Re:This is worth a Slashdot article?

[lucm]

What about DWR? http://en.wikipedia.org/wiki/D...

Or ST-JS? http://st-js.github.io/

The first rule of UI Thread.

[Kaenneth]

Do not block the UI thread.

Re:The first rule of UI Thread.

[Air-conditioned cowh]

That's old hat! On Android, everythinng blocks the UI thread!

Re:Clarity

[PopeRatzo]

RTFA

This your first time here?

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.

In node.js too ?

[jcdr]

Maybe in a future revision. This would bee great !

Re:In node.js too ?

[jcdr]

While I agree that node.js don't have a UI, it still have to balance the time passed to compile and the time passed to execute. AFAIK, node.js use a single thread loop for the execution and probably for the compilation too. I think that dispatching the compilation to a second thread could reduce the latency of the execution thread.

Re:In node.js too ?

[tgv]

It's fun for a few small applications, but beyond that, it's got to be horrible. I mean: imagine a server dying on the first uncaught exception...

Re:In node.js too ?

[jcdr]

AFAIK, uncaught exception is fatal in any language.

Re:In node.js too ?

[jcdr]

I suppose that it's possible to find the same opinion for any language. Actually it seem that Node.js raise in popularity.

Personally, I use it with Qooxdoo, and I found it a more effective solution that PHP for example. Having the same language in the server side and in the client side make the whole thing more coherent and simpler to maintain. I now experiment it for it portability across platforms to control a testing device from a browser.

Re:In node.js too ?

[tgv]

Not in an environment like Tomcat. It will just log the error, and restart the service.

Re:In node.js too ?

[jcdr]

... restart the service.

Yes, there is many ways to restart an application that died on a fatal uncaught exception. Again this is nothing specific to a language.

Re:In node.js too ?

[tgv]

Then again, nodejs is not a language.

Re:In node.js too ?

[jcdr]

Agree on that. Replace it by Javascript virtual machine in my previous text.
This is the same relation than with Java and his virtual machines implementations:
http://en.wikipedia.org/wiki/L...

Re:In node.js too ?

[tgv]

Yeah. I think Java's server options (Tomcat, or one of the lighter ones) are just more suitable as a run-time environment than nodejs for complex projects. Logging, multi-threading, loading the correct libraries, integration with maven (however unpleasant it can be), remote debugging, it all has been worked out pretty well by now. Nodejs is still years behind, it seems to me.

Re:In node.js too ?

[jcdr]

I don't pretend that Nodejs is comparable to Tomcat or similar options. I just noted that restarting on an uncaught exception, while not included in the Nodejs environment, is technically nothing special in Javascript virtual machine compared to others language. I have do that with a manager application or script in many projects. I will probably try to use systemd to do that in the future.

Re:This is worth a Slashdot article?

[Anonymous Coward]

I've been saying for years that Chrome was pathetic on how it makes poor use of multicore systems.

Javascript and threading being the number one problem.

The number two problem with chrome, click tools-task manager.
Browser 520MB
Tab Gmail: 120MB
Tab Twitter: 253MB
Tab Slashdot.org: 40MB (not Beta)
Tab Youtube: 94MB
GPU Process: 258MB
Plug-in: Shockwave Flash: 126MB

4 tabs open and 1.2GB of ram is consumed. This is a 32bit application.
Chrome needs to:
Enable 64bit mode, so leaking javascript apps like gmail and twitter don't crash after being open for half a day
Fix leaking Javascript
Make one-click flash be treated as though there is no flash installed OR flash installed. The former allows sites to fall back to html5 video if that is what the flash is, the latter just makes it no better than pathetic adblock.
Selectively disable Javascript functions for certain/all domains. I want eval() and document.write to die, as well as window.open()

Re:This is worth a Slashdot article?

[khellendros1984]

Except Java and Javascript share common letters in their name.

I like to say that java:javascript::ham:hamster. OK, yeah, I stole it.

Too Late

[Virtucon]

I've gone back to Firefox although I hadn't really left it. Why? Spying constantly and most recently disabling extensions without your approval and you have no way to re-enable them. This is because they want all extension developers to use their web store to funnel extensions out to the browsers, creating another fucking walled garden. I think it's not only time to de-Chrome but to de-Google completely, I'm tired of changing policies and them breaking shit just for shits and giggles.

Re:Too Late

[Frankie70]

My biggest question is why all Google products (Chrome, GTalk etc) install a Windows Service. Most other browsers manage well enough without needing a Windows Service?

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

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:History repeats itself

[dshk]

Actually it takes 70 ms to start (and stop) the JVM.

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: Call me...

[Anonymous Coward]

Dart is a silly idea in an age where we have vms running scripts in browsers. Even Mozilla knows to develop asm.js and let the user choose their language. If people can even use types on ES6 then Dart isn't necessary.

Hey bigmouth

[Anonymous Coward]

Hey bigmouth

Like calling folks idiots? Like this from you troll http://slashdot.org/comments.p...

Prove me wrong dumbass http://games.slashdot.org/comm...

It works, & gives folks what they want here (no beta site redirect foisted on them without asking, which is WHY I put it up... they did it to me 1 or 2 times, that beat it, & I gave folks what they wanted).

You're also FREE to *try* to disprove 17 points of FACT that use of custom hosts files gives users more speed, security, reliability, & even added anonymity that I list here where you can download it, free -> http://start64.com/index.php?o...

(Only thing is, on the latter, that FAR more skilled trolls than you have TRIED to, only to get shot down in flames each time, by yours truly)

APK

P.S.=> Come on big talker - go for it: I'll eat you ALIVE here publicly just to laugh @ your DUMB ass even more...apk

Re:This is worth a Slashdot article?

[viperidaenz]

What about them? Javascript happens to be the most popular browser language. Java happens to be the most popular typesafe server-side language with the best tooling support.

You forgot to mention GWT, which compiles Java to Javascript as well.

Re:Google Invents Multithreading

[Anonymous Coward]

One can always find predecessors for any technology going back to the Flintstones era. Of course, there were many attempts at vector processing, SIMD, instruction pipelining, dual pipelines, speculative execution and so forth going way back to the early days of modern computing. Most of these early efforts were very low-level in nature.

I think the modern concept of threads was solidified by the Mach kernel group at CMU in the late '80s. Chances are, they picked up on some academic research that was working as a proof of concept in some other university labs, and made it suitable for actual general purpose use.

Chrome's been there, done that

[rsilvergun]

there's a cut down JavaScript spec designed to work around this very issue. Static typing and all that jazz :P.

Re:Chrome's been there, done that

[ChunderDownunder]

I thought TypeScript was only available on a Microsoft platform. :-)

Re:Chrome's been there, done that

[marsu_k]

If you're referring to asm.js, shouldn't that be static-ish typing? ;) (see "intish" and "doublish")

Re:This is worth a Slashdot article?

[TheRaven64]

Especially if they've set the thread priorities correctly. The compilation thread should have a lower priority than the interpreter thread, so it will run in the gaps where the interpreter is waiting for input (and a little bit anyway). The interpreted code will be slower than compiled, and may remain interpreted[1] for longer, but the compiler won't be preempting the real work, as happens when they do it synchronously.

[1] 'Interpreted' in V8 really means compiled with no optimisations.

Why no precompiled code?

[allo]

When its compiled to platform independend sandboxed binaries, why can't the website provide this? This would safe a lot of compiling on the clients.

Re:This is worth a Slashdot article?

[superwiz]

running chrome on single core? that's an adventure. chrome takes 100mb just to sneeze and say hello. oh, and don't you dare live it idling for 5 mins. that'll be 1mb per min, thank you very much. yeah, yeah... memory has "nothing to do with the number of cores"... except being HIGHLY CORRELATED... c'mon... i dare you to say correlation does not imply causation... because causation is not the issue here... correlation (ie, simultaneous co-occurrence) is

Re:Hey bigmouth

[bondsbw]

Oh Lord, now that people know they can do this...

Slashdot has officially gone to hell.

Re:Still uses more CPU than IE/FF - Check plugins

[Tetravus]

If you've got lots of plugins for Chrome, try disabling most or all of them and see if that makes a difference. Plugins run in the same process as the browser and can add JS code to 'background' pages that are present in memory even when you're not interacting with the plugin.

Re:Still uses more CPU than IE/FF

[Elbart]

Why are you using Flash for Youtube in Firefox?

Re:Still uses more CPU than IE/FF

[ahabswhale]

You do realize you have to be running dev channel (chromium) to see anything different, right? That aside, I don't see what you did having anything to do with what they did. You're not testing what they are fixing.

Re:Still uses more CPU than IE/FF

[thegarbz]

Simple, I rarely use Firefox and as such everything is set at defaults. Why do I use it for IE? Because you can't do youtube any other way in IE9.

Re:Still uses more CPU than IE/FF

[thegarbz]

No I'm calling out the generic bull from the parent. Every time they announce a Chrome release some shill comes in and says IE is faster than Firefox and Chrome just like every time they announce a Firefox release someone bitches that Firefox instantly uses 100GB of ram just to display about:blank or some crap like that.

The fact is it's wrong. At least on default setups. If the GP somehow stuffed up his install or loaded some resource hungry plugins than that's his problem. No reason to spread miss-information though.

Re:Hey bigmouth

[lucm]

I don't know who wrote this bot, but the fact that it is adapting its babbling to recent events (like beta) shows that it is evolving, and this is a breakthrough in the area of Artificial Stupidity.

It's actually about Software Engineering!

[billstewart]

Yeah, it's worth a /. article, even if you don't like Google. It's an interesting analysis of an architectural change - what's the best way to do some complicated but common things.

Re:This is worth a Slashdot article?

[poetmatt]

Fair enough, I do forget to separate the two. I do assume you understood what I meant, though.

Re:This is worth a Slashdot article?

[snadrus]

Advertisers live by document.write.
Window.open is required for bookmarklets and reparenting to avoid windows being monitored by their creator.

Yes eval is trouble, but I'd rather see a badge indicating "easy to hack" when "use strict" is not in use. Many sites still use eval, so it's best to single them out vs breaking them.