Google Quietly Posts Big JavaScript Engine Update

An anonymous reader writes "Google has updated the Chrome JavaScript engine from version 2.5 to 3.0, which apparently results in some big performance jumps. ConceivablyTech has run some benchmarks on two different PCs and posted charts showing that the latest nightly builds are up to 100% faster than the Chrome browsers with the JavaScript version 2.5 (which would be all currently published Chrome 8 and 9 variants). Especially V8 and Kraken seem to benefit from the upgrade, while Google has now at least on some system the fastest Sunspider browser again."

Comments

!quietly

[yincrash]

this was part of their big chrome os announcement. i would say that is the opposite of quietly

Re:!quietly

[Monkeedude1212]

Yes but they whispered it into the microphone.

Getting a bit . . . skeptical about huge boosts

[JSBiff]

I realize that, from the baseline starting point of JavaScript interpreters in past years, there was a lot of room for improving the performance of JavaScript. But, when Chrome was first released, it boasted huge improvement in JS performance vs. other browsers, and it seems like every release since then has had these huge jumps in performance. . .

Shouldn't we be nearing some sort of point of 'it's about as optimized as it can possibly be and still give correct results'? If it's true, it's great, but getting 80%+ jumps in performance every major browser release doesn't seem like it could possibly continue for too many iterations.

Re:Getting a bit . . . skeptical about huge boosts

[MozeeToby]

Lets say a page takes a ridiculous 10s to run on the old browsers, Chrome comes out and takes 5s off that number so now it's 5s. Their next update manages to shave another 2s off, that's a 40% reduction right there, even though it's less than half the improvement the previous version gave. Then they shave another 1.5s off, the new engine is twice as fast. We look at things in ratios, which is the way it should be when looking at incremental improvements, but it means that when you're talking about fractions of a second, it doesn't take much improvement to make for accurate 'twice as fast' type claims.

Re:Getting a bit . . . skeptical about huge boosts

[Anonymous Coward]

Not true, it is just the other way around. As time goes by 100% improvements, even if it means little difference, becomes orders of magnitude harder to achieve.

Re:Getting a bit . . . skeptical about huge boosts

[JSBiff]

Yeah, I realize the starting point was horribly bad, so I realize there's room for a few generations of 80-100% improvements, but it would seem like, at some point, you've found all the 'easy' optimizations, and it should start to get very hard to improve it further.

Instead of thinking about TIME, let us think, for a moment, about OPERATIONS. A 100% performance improvement means that, in the same time, you do twice as many operations. So, you start out doing 1E6 operations/sec. You double that and you're doing 2E6 operations. double that again and you're doing 4E6 operations. There comes a point, sometime, where the code is about to 'native' performance, and can't possibly run any faster - because the processor can only do so many operations per second.

There's also the issue that, processor speed isn't the *only* thing that can potentially slow JavaScript down - there might be network I/O (if you're doing some sort of AJAX-y type thing with a remote server), disk I/O, graphics/rendering lag, etc.

At some point, a faster JavaScript engine becomes somewhat academic because even if it's true, the JavaScript has to wait on the browser to render HTML, images, play sound, load remote content, etc.

Re:Getting a bit . . . skeptical about huge boosts

[Requiem18th]

Personally I'd suggest using this period of constant innovation to do something bold like embedding a sandboxed VM of java, or python, or lisp, or anything with strong types and good exception management.

I understand if browsers have to support javascript until the end of times, but there shouldn't be anything stopping all the browser makers from embedding a BSD'd, shared implementation of a scripting engine. Of course it going to be hard to implement but it's still several orders of magnitude easier than, say the change from analog to digital tv.

I understand that javascript is not as bad as they make it to be but it's far from the optimal solution.

And stop being pussies about hurting users. As a web developer there was a point when I said, to a client company, "such and such features aren't supported in IE6" and suddenly IT lifted the restriction to IE6,

Users are more flexible than you think.

Stability

[ifiwereasculptor]

I've been using Chrome for ages, but it seems to me like it's already way faster than it would have to be. I use a very dated machine and cannot usually saee Chrome being much faster than Firefox 3.5.12. They should be focusing on improving stability, because since Chrome 7 I've been experiecing unresponsive tabs, tabs that just won't load anything while others do fine and a plethora of other annoyances. Plus it can't really handle /.'s text box. I can't even go back with my mouse to correct a "saee" that's been bugging me for seconds!

Re:Stability

[ifiwereasculptor]

Broken metaphor. When I get new keys, if they fail to start the engine while my old key worked fine, then yes, I replace the keys. Pay attention. I said "since Chrome 7". 6 worked fine and Firefox 3.5/3.6 still do.

Re:100%! OMG

[adisakp]

Can we come up with a standard way to convey the concept of speedup people? I have a feeling that they meant twice as fast. 100% faster would mean it finished instantaneously, which might be true if the benchmark was all marked as dead code... Oh, this is about google, not MS. My bad.

The article is correct: 100% faster is twice as fast. 100% less time would be instanenous.

Say I drive from point A to point B and it takes 10 minutes. Now I repeat the route but I drive 100% faster -- the results is it only takes 5 minutes; I have doubled my speed and halved my driving time.

The Golden Age of browsers

[Sparkycat]

We'll all look back on this era as a golden age for browser competition and progress.

I can't even think of an analogous situation, with four different entities with vastly different philosophies, improving their browsers at a breakneck pace, embracing(at least publicly) open standards over proprietary technology, and competing almost exclusively on the merits of their products.

Re:Javascript is the new MHZ-race

[afidel]

Actually this is the opposite of the MHz wars as it is about being more efficient, and since getting the rendering done faster means you can put the processor back into deep sleep it's about better battery life as well.

Re:The Browser Wars

[Anonymous Coward]

No.

"The browser war continues"
-or-
"The browser wars continue"

Either would be fine, but "The browser wars continues" is certainly not proper English grammar.

Mod me as troll or whatever makes you feel better about yourself, but it doesn't make it any less true.

Re:Javascript is the new MHZ-race

[ifiwereasculptor]

It's about being faster, not necessarily more efficient. The OP's got a point. JS benchmarks seem to be trumping memory usage and whatnot in importance.

Re:The Browser Wars

[julesh]

Or... "The browsers wars continues"

"... after this commercial break"?

(That's about the only way I can make sense of that sentence.)

trickle down?

[sl0ppy]

wondering how quickly these speed increments will "trickle down" to projects like node.js.

i'd love to see speed increases as the javascript engine matures.

Re:The Browser Wars

[Fry-kun]

Or... "The browsers warses continueses"

Fix'd

Re:The Browser Wars

[adamofgreyskull]

I'm froms News News Yorks and I likes the ways youse thinks.

The world does not live by Javascript alone

[bradbury]

Now if they could just address some *real* world issues. Like large session restores (dozens of windows/tabs) or browsers that don't eat CPU time when they are idle (all windows minimized and/or inactive). There are many users who view Javascript as inherently evil and think the Web would be better off without it. Its *my* PC and should only be running open source code which many eyes have looked at (not true for a majority of Javascript loose in the wild).

Until they get the session restore and CPU issues right the browser IS NOT GREEN. The people benchmarking browsers or reviewing browsers need to think a bit more outside of the box that seems to consist only of "How fast does Javascript run?" or "How many of the HTML 5 tests does it complete?"

For example, "What is the minimum memory that a browser requires for a specific set of sites?", "What is the system load, e.g. processes, file handles, disk I/O's, etc., to load a specific set of sites?", "How does the browser perform when one exceeds RAM memory? (is the current Window/tab responsive?)", "What is the largest HTML document I can load and how long does it take?", "How long does it take to complete loading a complex diversified page, e.g. one which loads sub-elements from 50-100 other sites?"

The stress and performance testing of browsers seems confined to a box whose dimensions are typically measured in angstroms!

Re:The world does not live by Javascript alone

[catbutt]

There are many users who view Javascript as inherently evil and think the Web would be better off without it.

How many, really? Are these the same users who think the web would be better off without any advertising? Just a guess, but those users probably don't weigh heavily in google's priorities.

Its *my* PC and should only be running open source code which many eyes have looked at (not true for a majority of Javascript loose in the wild).

If you apply that to sandboxed, interpreted languages....you might as well also apply it to html. Html, while not really a programming langage per se, does instruct your computer what to do. If the browser has a bug, malicious html can cause harm to your computer or compromise your privacy. What it the difference?

Re:Javascript is the new MHZ-race

[edumacator]

A billion here, a billion there, and pretty soon you're talking about real gigabytes...