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

The Browser Wars

[BlkRb0t]

continues.....

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:The Browser Wars

[hvm2hvm]

Or... "The browsers wars continues"

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

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.

Re:The Browser Wars

[TheKidWho]

Languages evolves mans. Back to the académies françaises with yous.

Re:The Browser Wars

[Gilmoure]

Dude! Yur speakin' all Cajun en shit.

Re:The Browser Wars

[Anonymous Coward]

Ur ryt. T dozt mtr hw u spk. Lyk rly cum on u no? Y evn hve ny stnrds? Ts evulution!

Re:The Browser Wars

[0100010001010011]

And google is definitely firing the first Salvos.

They took out a full page ad in my college's newspaper. With just the chrome logo and a "Give the gift of ....." and then a link to google.com/chrome.

Daily newspaper for a college campus of ~50,000 students. I know Firefox did the one ad a long time ago and I've never seen an Ad for IE. (other than MS in general). So Google is definitely going at this 'war' full force.

Re:The Browser Wars

[Anonymous Coward]

I'm sure my HS English teacher would have had a field day with this gem:

  "Especially V8 and Kraken seem to benefit from the upgrade, while Google has now at least on some system the fastest Sunspider browser again."

Re:The Browser Wars

[An ominous Cow art]

Yoda: "Continues, this Browser War does."

Competition

[Anonymous Coward]

This is the kind of competition we should see everywhere. Not just browser speeds.

Re:Competition

[Anonymous Coward]

That on ESPN Cinco?

100%! OMG

[Anonymous Coward]

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.

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.

Re:100%! OMG

[AvitarX]

I like this: www.youtube.com/watch?v=nCgQDjiotG0

It has that whole library of congress per statue of liberty feel to it.

Re:100%! OMG

[Anonymous Coward]

100% faster is twice as fast.

That's unecessarily confusing. Just say twice as fast. Percentages aren't needed.

Re:100%! OMG

[adisakp]

100% faster is twice as fast.

That's unecessarily confusing. Just say twice as fast. Percentages aren't needed.

In the article the OP complained about, the actual number was 109% faster - I just gave a simplified example with round numbers. Following your advice, I'd have to say "a smidgen more than twice as fast" which really isn't that accurate. Sometimes numbers and percentages are not only useful but required to represent information accurately.

Re:100%! OMG

[TheThiefMaster]

209% of the speed?

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

Re:!quietly

[Anonymous Coward]

The repository was updated before the announcement. ConceivableTech was apparently one of the few that noticed it before the actual announcement.

Re:!quietly

[pwagland]

The repository was updated before the announcement. ConceivableTech was apparently one of the few that noticed it before the actual announcement.

This would appear to be the case, as they have updated the story to point to Google's blog post on the crankshaft update.

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

[Monkeedude1212]

Haven't you SEEN that commercial where they shoot the potato through the dicer in front of the computer screen? That was close!

I think they hope to have the page load before the table salt hits the apparatus.

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

[Monkeedude1212]

This is a good point. 100% improvements should actually be easier as time goes on.

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

[A beautiful mind]

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.

A more realistic scenario would be saying that if ideal page load time is sub 500ms or so, then it is possible to do a lot more in that time with this upgrade. Google doesn't want to reduce the load times, it wants to do more in a given amount of time, when considering applications like GMail, spreadsheets, etc, while still providing fast page load times.

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.

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

[shutdown -p now]

As JS is a late bound language, the quality of implementation is largely dependent on its ability to analyze code and predict call targets and call environment in advance. While the idea itself is not new, it is a field where the real progress has only just started. There are likely still many undiscovered techniques at making that analysis better, and I would guess that it is what Google does.

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

[Anonymous Coward]

This is what the mozilla guys were talking about earlier this year. It is also why they came up with kraken. They were starting to see all of the browser 'speedups' becoming quite negligible on v8 and sunspider and flat lining. Also those particular bench marks are really meant to show off webkit and chrome. Mozilla came up with a benchmark of where they think the web is going. You will see a few more benchmarks suits before this is done.

But yes if you go from 2ms to 1ms http://arewefastyet.com/individual.php which you can see in some of the benchmarks. It would be a 100% improvement.

It really is a fairly mixed bag of who is faster. As what Mozilla also found was that some parts of the tests are weighted more than others.

But good on chrome for making the bar higher.

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

[nschubach]

Can't wait to start coding JS in Node.js for all my business needs!

Kind of a joke, and not at the same time... I really like being able to do all the stuff JS allows (eg: lambda like functionality [not a fan of of the lambda syntax in C#]) but until recently it seemed speed was less than dirt in priority. If only they added a bit more sane (ie: built in) method of loading "libraries" besides XMLHttpRequest/eval()...

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

[jandrese]

Given how godawful slow Javascript has been in the past, there is a lot of room for improvement. Google is especially interested in fast Javascript, because so many of their services are very JS heavy and the quality of the user experience is harshly affected by old slow JS interpreters.

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

[shutdown -p now]

I really like being able to do all the stuff JS allows (eg: lambda like functionality [not a fan of of the lambda syntax in C#])

Out of curiosity, why? It would seem to me that this (C#):

(x, y) => x + y

is much preferable to this (JS):

function(x, y) { return x + y; }

especially in the so common one-liner scenarios for lambdas. For multiline ones, the difference in syntax is really marginal - drop "function" and add "=>" between the parentheses and the curly braces, and that's it.

Or did you mean the old C# 2.0 "delegate(...) {...}" syntax, which required fully spelling out parameter types? If so, there is no reason to keep using it today - it is there solely for backwards compatibility.

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

[nschubach]

The delegate method was the one I was used to... the new one looks intriguing but => and >= feels like we are getting back into the whole C debate on >> usage and how a symbol mistake can change the meaning of the program more significantly than you may want. I assume (x, y)=>{x + y} is equivalent to what you have above? I might have picked another symbol other than =>... eh, it matters not.

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

[mutube]

Not sure if you're getting the parents point (apologies if you are, I might be misunderstanding you!)

Original speed = 10s load time
2x as fast (100% improvment) = 5s (5 second improvement)
2x as fast again = 2.5s
2x as fast again = 1.25s
2x as fast again = 0.625s (0.625 second improvement)

So the longer it goes on the less actual improvement 100% represents - and less noticeable. I think its difficult to judge the value of these results without absolute times.

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

[Idiomatick]

http://www.youtube.com/watch?v=nCgQDjiotG0&fmt=18

Seriously fast!

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

[shutdown -p now]

=> and >= feels like we are getting back into the whole C debate on >> usage and how a symbol mistake can change the meaning of the program more significantly than you may want.

I'm not sure what debate in C regarding ">>" you're referring to; did you mean the overload of that operator in C++ for iostreams?

If so, this case is quite different because "=>" was never a legal operator in C# before. I agree that it looks somewhat similar, but mixing it up with ">=" in practice is pretty much impossible because the types of expressions are so different. You can come up with contrived cases, of course:

void Foo(bool b); // #1
void Foo(Func<int, int> x); // #2
 
int x = 0;
Foo(x >= x); // calls #1
Foo(x => x); // calls #2

But in practice the chance of getting this kind of thing in real code is non-existent.

They'd probably use "->" to differentiate better, and conform to existing custom as seen in ML, Haskell and elsewhere, if it wasn't already used for pointer field access.

I assume (x, y)=>{x + y} is equivalent to what you have above?

Not quite. If you use the braces, what's inside is a bunch of statements, same as in any other block - so you have to use "return" and terminate with a semicolon:

(x, y) => { return x + y; }

In the shorter braceless version, the right side of the arrow is syntactically an expression, hence no "return".

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

[msclrhd]

Exactly. Going from interpreted to a (simplistic code generation) method jit is reasonably straightforward (assuming you know how compilers and assembly language works). From there, you can analyse the parts of the code generation that are slow and produce better code for them (e.g. using the INC operation for ++i instead of ADD 1). Then you need to start doing run-time hot-loop/hot-code optimisations on the fly which is what tracemonkey and this are doing. Getting this working is around the same complexity as the method jit, integrating the two is harder (when to run the optimiser, when to bail out). After that, you are into type inference/static analysis territory. Some experimental patches that the Firefox team are working on show ~35-40ms improvement on the spidermonkey tests. Other optimisations are possible from the inbuilt knowledge of the types.

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

[Johann Lau]

I'm more "pussy" about parentheses myself. Python might be nice, but I'll never use it simply because it doesn't have any. Now C++ on the other hand, that would kick ass...

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

[gl4ss]

no.. it's just that chrome pr guys bullshitted so widely with their initial press releases about chrome.

I'm sure everyone who had an early version of the comically hyped chrome knows what i'm talking in regards of the overhyping if they had an instance of chrome crash all the tabs at once - which was exactly opposite of what their advertising material had promised.

it's also about choosing to use different measurements for every iterations benchmarks, say, you got a feature that you got working really well.. well, you can't optimize it any further so you start to work on some other test case, only this time you'll use a test that tests only that to make your performance increase claims for this round to be high too.

now, does this extra speed bumps enable new kind of applications written in javascript? not really and that's what matters.

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

[JSBiff]

Yes, I get that, but you're missing my point, I think.

In math and science classes, you might talk about the relationship between frequency and period. For example, with an oscillation like an A/C electric current, or radio/light wave, period is how much time it takes to complete a single cycle, frequency is how many cycles occur in a fixed time period (usually, 1 second). Mathematically, period = 1/frequency, and vice versa.

What I'm saying is that going from 1.25s to 0.625s, even though it doesn't sound like a big deal because it looks like a really small change in time, really is a big deal, because it means that JavaScript engine or browser is (nominally) doing twice as much stuff per unit-time. It's like the difference between period and frequency.

There is, of course, one flaw in this analogy - with computer programming systems, often time speedups are achieved through efficiency gains - using improved algorithms so you can get the same final result with much less work. Working smarter, not harder, so to speak. But, even with optimizations like that, at some point, you've got to reach an absolute minimum - where you cannot possibly reduce the workload any further and still get the correct, expected result.

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

[Requiem18th]

Python supports parenthesis with custom delimiters provided you keep your code indented:

class Dog: #{
        def bark(self):#{
                print "bow-wow!";
        #}
#}

Of course you can stop intenting using this
from __future__ import braces

But C++ sounds great! Yay buffer overruns!

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

[Johann Lau]

uhm no, python supports comments. that's hardly the same. oh, and it requires a # on every comment line, that's another no-no for me... you know, what happens if you want to comment out something *within* a line? as in

if (testcondition1 /* || testcondition2 */)

? for the life of me I don't get why people would not re-use such, uhm, advancements in computer technology. as cumbersome as c++ may be, it can also be very sweet. not to mention fast.

But C++ sounds great! Yay buffer overruns!

oh come on, it's not like if you pay attention you cannot avoid that? that's an argument against shitty c++ code, not the language itself. obviously it would have to be run in a sandbox, but so does everything else anyway.. so yeah, integrate GCC in the browser, compile the scripts as they come in, and BLAMMO, quake live actually IN your browser etc.

WebGL really might make the scripting language the bottleneck for many things (network stuff aside of course). and c++ is nice. so it'd be win/win ^^

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

[Requiem18th]

Congratulations, I'm not sure anymore if you're just a humorless clod or a subtle troll.

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

[Johann Lau]

oh yeah, right.

you say people should not be "pussy" and embed "anything with strong typing."

so I mention the reason why I CAN'T like a language I'd actually like to like (python), and c++.

then you say python "supports brackets" with its hilariously basic comment syntax... and how c++ has "buffer overflows" as intrinsic disadvantage. you know, both of those are bullshit, and now you've run out of anything to say you get to call me troll? humourless no less, which is ironic to say the least.

well, you could also say c++ is like a sports car (hey, car analogies! haha), without all the shitty stuff weighing those down who know what they're doing. and that's coming from someone who can hardly code c++ without producing crashes all the freaking time - I still can see the beauty of the language in those instances I use it somewhat correctly. I can also see the eyecancerfest some other languages are. then I compare performance and hey, I'm sold.

you're talking about the future here after all, and not being pussy and doing some real leaps forward. so fuck sandbox VM - and bring on the sandbox compilers :P

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

[Johann Lau]

and and sure, so you were joking about the brackets.. way to "discuss" tech stuff, gah. I stand by it, blehhhh to most of the languages you mentioned. yay c++.

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

[oravecz]

Out of curiosity, why? It would seem to me that this (C#):

(x, y) => x + y

is much preferable to this (JS):

function(x, y) { return x + y; }

and is syntactically sugarlicious in JS 1.8 (MDC link) :

function(x, y) x + y

In the SSJS space, some frameworks support more recent JS specifications which include some more interesting language capabilities than lambda syntax. One of my favorites is destructuring assignment which is used often with the require() function in a way similar to Java's import statement.

New in JavaScript 1.7

New in JavaScript 1.8

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

[shutdown -p now]

It's better, but, so far as I know, it's a Mozilla language extension, and is not part of the EcmaScript 5e - and thus not portable.

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

[Anonymous Coward]

I use a very dated machine... I've been experiecing unresponsive tabs ... that just won't load anything ... and a plethora of other annoyances.

When your car breaks down, do you replace the keys because they fail to start the engine?

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

[increment1]

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.

Improving Javascript speed allows for more complex and feature rich Javascript applications to be developed. The whole impetus for Google to develop Chrome can likely be traced back to their desire to have a fast and stable platform on which they can deliver their web applications.

If we consider Google's Javascript based word processor and spreadsheet applications then it is clear that the speed of the underlying Javascript engine is a key component in the applications' usability. Pushing the pace of Javascript development directly allows Google to expand the functionality of its web applications and compete more evenly with non-web based applications.

Re:Stability

[dingen]

I've been using Chrome for ages

Seriously? The initial release of Chrome was in September 2008, so you've been using it for just over 2 years now if you started using it right when it launched. Is that what people are calling "ages" these days, two years?

Re:Stability

[Anonymous Coward]

Slashdot's text box is a problem in chrome, yeah. The other issue is broken copy+paste (at least on the linux versions, and yes, I'm up to date.)

However, it seems to work fine on other sites so I'm not sure if that's a chrome issue or something unique to Slashdot. Lets face it... /. isn't exactly leading the technology pack.

Haven't had any problems with lockups - and this is on an old Athlon XP (1050Mhz, 1Gb RAM). Compositing doesn't seem to affect performance except when playing flash videos. That said, if I get a few dozen tabs going it starts to slug a bit. Shift+ESC brings up the task manager, and killing the flash process from there gets everything running well again, so I suspect that flash is the problem moreso than Chrome.

Re:Stability

[f.ardelian]

ifiwereasculptor: that happened to me too, once. I'm a FF4 user now... (sorry, guys!)

Re:Stability

[D Ninja]

Plus it can't really handle /.'s text box.

Now now. Let's keep our expectations realistic.

/take it how you want

Re:Stability

[ifiwereasculptor]

Machine load doesn't really matter here. It tends to get unresponsive especially with CSS-heavy pages. By the way, Chrome 8.0.552.215 allows copy+paste. Really, it does. Really, it does. Really, it does. Really, it does.

Re:Stability

[nschubach]

Obviously, since an astrological age is about 2000 years the OP has been using Chrome for at least 4000 years.

Re:Stability

[Barryke]

Plus it can't really handle /.'s text box.

I was thinking i was the only one.
For some reason (on some W7 systems) i can't cut-paste inside the SlashDot text box when using Chrome. Thank god for the Quote Parent button though.

Re:Stability

[brusk]

It's a known bug (regression, actually). http://groups.google.com/a/chromium.org/group/chromium-bugs/browse_thread/thread/e6cf782339d6f9a7/07d315c528d670cc?lnk=raot&pli=1

Enough with 'quietly,' already!

[Anonymous Coward]

There's nothing 'quiet' about posting a big writeup to your weblog http://blog.chromium.org/2010/12/new-crankshaft-for-v8.html

Similarly, 'quiet' would seem to indicate that no-one noticed anything had happened. Currently, the news was whispered less than three hours ago and it's currently on techmeme, hacker news and here. So, so quiet.

Javascript is the new MHZ-race

[Anonymous Coward]

I wouldn't want to use any site where these ever-amazing javascript improvements are necessary. Also, they should stop reporting in percent now that they're (I'm guessing) in the sub-millisecond domain.

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:Javascript is the new MHZ-race

[Anonymous Coward]

I can assure you, the general population is not Luddite nerds who wish that everything stayed 70s style green screens. You don't stand alone with your "I hate JavaScript" mantra, but you aren't in a big crowd, either.

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:Javascript is the new MHZ-race

[julesh]

I wouldn't want to use any site where these ever-amazing javascript improvements are necessary.

Are you going to stop using slashdot, then? Because, believe me, if you're going to run the most recent version on a typical handheld device processor (single core, single dispatch, usually about 5-600MHz), you're going to be feeling the sluggishness unless you're using a pretty good javascript implementation.

Re:Javascript is the new MHZ-race

[19thNervousBreakdown]

Given the amount of RAM installed in standard computers today, what's a couple billion bits between friends?

Re:Javascript is the new MHZ-race

[edumacator]

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

Re:Javascript is the new MHZ-race

[Anonymous Coward]

No self respecting nerd would call them "70s style green screens."

You must be a terrorist.

Re:Javascript is the new MHZ-race

[The End Of Days]

You're mistaking efficiency for that weird Slashdottian desire to have RAM sitting there doing nothing - which still consumes power and so is actually the opposite of efficient.

Re:Javascript is the new MHZ-race

[Anonymous Coward]

Because, believe me, if you're going to run the most recent version on a typical handheld device processor (single core, single dispatch, usually about 5-600MHz), you're going to be feeling the sluggishness unless you're using a pretty good javascript implementation.

Yep. Slashdot is pretty damn bad on the HTC Desire (1GHz Snapdragon processor) using the built-in webkit browser (which I think has a JS engine from the same team). Idle in particular is unusable, and expanding a front page story can take upwards of 30 seconds.

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.

my own benchmark

[MichaelKristopeit211]

to convince a friend that his theories on craps gambling were incorrect, i made some simulations software... when i first made it, running 30 sessions worth of simulations would take almost a minute... with the latest chrome beta running on OS X on an intel macbook it's almost instant.

it contains a lot of random chance and comparisons and stored math... a good test of raw computational ability.

I hope they make a Javascript API to Android

[catbutt]

Since Android already has Google's JS engine (in the browser), why not make it so you can write native apps in it? As in, ones that can access everything you can access from java. It might be slightly slower, but I doubt by much....especially since most of the intensive stuff (say, animations) can be done by OS. I work with both languages on the platform, and having to use java is just painful for the stuff that is so easy in javascript. Javascript may not be a perfect language, but its got so many advantages over java in a mobile device. Also the relationship of Java to XML/view layout on Android is so close to the relationship of Javascript to HTML/DOM in browsers.

The other obvious benefit would be that with Chrome OS and Android being effectively competitors, this would help tie the two together....easier to write apps for both if they use the same language. (and then there's that Oracle thing)

Re:I hope they make a Javascript API to Android

[AusIV]

Look at phone gap. I just discovered it today, so I don't know if it's any good, but it looks like what you're talking about.

Re:I hope they make a Javascript API to Android

[Anonymous Coward]

Lua to Android would be better. Lua would make a better Javascript than Javascript.

Re:I hope they make a Javascript API to Android

[catbutt]

Well aware of phonegap. It works by doing everything in WebViews, which makes it slow, clunky, and unable to do a lot of things that you can do in native views. For what it's worth, I do a lot of work on WebViews with javascript in Android apps (without phonegap), but it is a hacky solution at best.

Re:I hope they make a Javascript API to Android

[catbutt]

Unless Lua runs in all popular web browsers as a replacement for Javascript, using it as for the Android SDL would defeat much of the purpose of what I suggested.

Re:I hope they make a Javascript API to Android

[acidblue]

Well, then look into the Titanium framework. You code in JavaScript (and HTML, CSS) and it cross compiles to native apps for iOS, Android, Blackberry and desktop apps. http://www.appcelerator.com/ I have only dabbled for a short time, but seems quite cool.

Re:I hope they make a Javascript API to Android

[icebraining]

So, reinvent XUL? Applications made in JS with XML views, downloaded on demand with access to the system APIs. Seems to fit the bill.

Re:I hope they make a Javascript API to Android

[lilo_booter]

Have fun. Haven't tried lua here yet, but python works fairly well.

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:trickle down?

[jchernia]

I would love to see these trickle down to a Java Embeddable engine like Rhino

Re:trickle down?

[after.fallout.34t98e]

V8 is an embeddable engine.

IMO it is actually easier to use than Rhino.

From C++: http://code.google.com/apis/v8/embed.html
For .NET apps: http://javascriptdotnet.codeplex.com/
python: http://code.google.com/p/pyv8/
ruby: https://github.com/cowboyd/therubyracer

...

Speed

[KiloByte]

Chrome FASTER than Firefox? What the hell. For me, it's around 5-8 times slower on an average website -- little difference on Slashdot, tremendous on, say, CNN.

This is easily explained if you cut yourself and disable AdBlock -- the speeds will be similar.

Somehow none of lists shipped with AdBlock do something to all that 15th party tracking, you need to purge them yourself, but even in the default settings the difference is still hugely in favour of Firefox.

This is an optimization Chrome's authors should do instead of shaving another fractions of second in JavaScript performance -- but sadly, they get their income from peddling crap :(

Re:Speed

[SmilingBoy]

You know there is AdBlock for Chrome? Works perfectly!

Re:Speed

[KiloByte]

It merely hides stuff from view rather than actually blocking it. There are attempts to make it work but as the author says, Chrome doesn't provide necessary API to do that.

Re:Speed

[Score Whore]

It'll likely never do that. This is Google. If they had a choice of leaving Eric Schmidt's head up your ass or removing his head and curing cancer, they'd start building more cancer wards.

Re:Speed

[Anonymous Coward]

No, it doesn't "merely hide stuff". It blocks it. There is a Chrome API for blocking.

Re:Speed

[Anonymous Coward]

WRONG.

Get updated information before spitting out incorrect info.

Re:Speed

[Anonymous Coward]

...yet. They're working on it.

There are other, better solutions, though.

Privoxy.

Re:Speed

[SmilingBoy]

This was the situation about half a year ago. Since then, AdBlock for Chrome has blocked ads from being downloaded.

Re:Speed

[the_other_chewey]

Somehow none of lists shipped with AdBlock do something to all that 15th party tracking, you need to purge them yourself,[...]

So what is the EasyPrivacy list then?

It has been decided at least two years ago to put the tracking filter rules in their own
list, because they obviously don't belong in a pure adblocking list.

Yes, there had been complaints by people who wanted ads blocked but the
tracking stuff left intact.

Chrome is completely broken for me

[eminencja]

How sad I cannot use Chrome until they fix this bug: http://code.google.com/p/chromium/issues/detail?id=47416 The most innocent applications (framesets with documentation, TOC/Search on the left, actual content on the right) do not work in Chrome if loaded from a local hard-drive (or chrome is started with some weird, undocumented switch). Those framesets worked fine even in Netscape 4 and ancient versions of KHTML.

Re:Chrome is completely broken for me

[hydrofix]

You have to disable the same origin policy with the switch --disable-web-security. Use the browser session with this switch strictly only to browse the documents on your local hard drive, or malicious websites can read your home files etc. nice stuff.

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:The world does not live by Javascript alone

[MrNemesis]

Commenting instead of moderating, and I agree - browser reviews appear to have devolved into "Browser X is best at Benchmark Y and Z, and is therefore the best browser!" when, as far as I can tell from my real-world usage, there are many more glaring deficiencies and advantages that are ritualistically ignored in a market where all browsers are rapidly approaching "good enough". For example:

* Firefox still eats too much memory, and still slows down to a crawl once it eats >1GB (even on a machine with 16GB RAM), but still has the unbeatable AdBlock
* As you point out, Chrome eats lots of CPU, it uses a poor-man's AdBlock but it's, er, quite fast at javascript and HTML5
* Opera still doesn't play nice with certain proxies (mem leak and ever-increasing CPU usage), still has problems with rendering certain sites (not necessarily their fault) but is the only browser with decent gesture support

You just don't get browser reviews like this because it's just easy to trot out the numbers and call it a benchmark review, which makes for cheap copy and lots of page hits from "first Browser X reviews hit teh intrarwebz!". You may find the occasional site that actually reviews the browser, but they're lost in a sea of mediocre bar graphs with little to no "but what's it LIKE?!" commentary, because doing that sort of review requires you to understand and actually give a shit about what you're reviewing, and depressingly few people seem willing to put the time in.

Re:The world does not live by Javascript alone

[bickle]

How many, really?

Well, according to the Firefox addon page, NoScript has 367,131 weekly downloads.

Re:The world does not live by Javascript alone

[Abcd1234]

Oh ffs... yes, I'm sure all NoScript users disable all javascript on all sites all the time.

Please.

Hell, I have NoScript automatically whitelist all subdomains, specifically because I *want* JS to work, I just don't third-party crap to work (unless I've whitelisted it).

Yes!

[bonch]

Yes! Text will load even more imperceptibly quickly!

Re:Yes!

[VortexCortex]

Yes! Text will load even more imperceptibly quickly!

And so will my HTML5 games!

Re:Stability, Bigger Picture

[Anonymous Coward]

You're not seeing the bigger picture. See that other /. post above, on the main page, regarding Chrome OS? Google isn't doing this work on Chrome to make it a better browser. They are doing this work on Chrome to make it work as the OS workhorse of the computer, delivering all your applications and data via the web, instead of desktop applications. The push in this direction means much heavier JS applications.

When talking about Google, you can't just look at a single product how it affects you today, but taken in the context of their other products and their desire to control/organize the worlds information.

So how can I tell if it's installed?

[billstewart]

Chrome says it's up to date, and I'm running an 8.x version - does that mean it installed itself last night when I was asleep?

Re:So how can I tell if it's installed?

[devnull256]

go to "about:version" Mine says: "V8 2.4.9.14"

Re:So how can I tell if it's installed?

[billstewart]

Thanks - I got the same version number. Fark still crashes occasionally ("Oh, Snap!"), though it also runs faster when it's not crashing.

Firefox can burn my whole CPU TWICE as fast!

[billstewart]

If I'm reading a bunch of stuff with complex web pages (e.g. open all today's links from a news aggregator such as Fark in tabs, getting a wide mixture of badly designed web pages), eventually FF will start hogging the whole CPU and burning more RAM. Fortunately I've got a dual-core machine, so it normally only burns one core, and I can't actually tell if it's Javascript or Flash that's doing it, but I'm really much more interested in stability than speed at this point. Speed matters a bit after Firefox crashes, when I'm reloading the session, though that's probably limited more by dynamic web pages than by FF itself, but Chrome seems to load faster (it doesn't crash quite as often, but I also have to reboot the machine occasionally due to power issues or installing software.)

optmized for Mozilla Kraken

[savvyart]

Seems, Chrome team has finally gotten to optimize for the Mozilla Kraken. The gains in other benchmarks are about 10%. Nevertheless all progress is good, may be all this optimization will trickle down to some real world speed.

Re:optmized for Mozilla Kraken

[multipartmixed]

Another way to look at this is that by adding codegen that can do some kind of type specialization that they are seeing similar benefits to Mozilla's tracing JIT. If Kraken happens to benefit most from this class of optimizations, then the observations made could simply be the result of good code on Google's part, with no subterfuge or optimizing-for-the-benchmark going on.

Re:optmized for Mozilla Kraken

[caspy7]

Given that Mozilla's Kraken was designed to measure what they would perceive as real-world speed, then we should hope so.

A .069 Second Difference...

[Anonymous Coward]

...in the results of SunSpider runs between Chromium 10.0.605.0 and IE 9 Platform Preview 7 (1.9.8006.6000). I'm really enjoying this aspect of the slugfest between Google and MS.

Q&D Comparison Results

Chromium 10.0.605.0 results total: 279.6ms +/- 2.4%
IE 9 Platform Preview 7 (1.9.8006.6000) results total: 348.9ms +/- 0.8%

SunSpider 0.9.1 (http://www2.webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html) executed on ThinkPad W500, 2.53GHz Core 2 Duo (T9400), 4GB RAM, Win 7 64.

JS getting faster, other things getting slower

[kingbilly]

About 6 months ago I used chromium for my default browser, but recently I have had to launch Firefox more and more. 1) Adblock is missing ALOT of ads suddenly. Especially flash ones which really kill me on linux. It doesn't help that Adblock on chrome still actually loads ads and then hides them. 2) Websites like imdb.com with a center div that is styled with a shadow bring chromium to a crawl. 3) Chrome couldn't load Google Adsense or Gmail a few times, I had to start firefox instead. I have been watching tv for the first time since 2003 (when I discovered linux) and every couple nights I have to start firefox just to go to IMDB to lookup info about actors/shows.

Great. Web preview will suck faster now.

[jason8]

Ever since google decided to make their web search results unusable with the "Web Preview" crap (which pops up a huge, useless, floating window when you click on the text of any search result, and which is non-opt-out-able), they've made themselves an enemy of me. Or me of them. Whatever. I know it can be disabled via greasemonkey or noscript, but fuck it -- I'll just use other web searches, email, RSS readers, etc.

dunno about benchmarks

[perryizgr8]

load up a /. page with >1000 comments on a core-i3 machine and watch chrome stutter and sputter as you scroll at a blazing 5fps.
load up the same page on firefox latest stable and voila! the page scrolls ultra-smooth and absolutely no lags. so i'm kinda suspicious about the usefulness of tests like sunspider.