Chrome 10 Beta Boosts JavaScript Speed By 64%

CWmike writes "Google released the first beta of Chrome 10 on Thursday, and Computerworld found it to be 64% faster than its predecessor on Google's V8 JavaScript benchmarks. But in another JS benchmark — WebKit's widely-cited SunSpider — Chrome 10 beta was no faster than Chrome 9. Yesterday's Chrome 10 beta release was the first to feature 'Crankshaft,' a new optimization technology. Google engineers have previously explained why SunSpider scores for a Crankshaft-equipped Chrome show little, if any, improvement over other browsers. 'The idea [in Crankshaft] is to heavily optimize code that is frequently executed and not waste time optimizing code that is not,' said the engineers. 'Because of this, benchmarks that finish in just a few milliseconds, such as SunSpider, will show little improvement with Crankshaft. The more work an application does, the bigger the gains will be.' [Chrome 10 beta download here.]"

What About /. Performance?

[WrongSizeGlass]

Will it make the new /. work any faster ... or better ... or anything?

Pardon my ignorance(and I don't want a holy war)..

[fuzzyfuzzyfungus]

Historically, slashdot(and elsewhere) has seen the battle over performance between the C/C++ classicists, and those who insist that Java or one of its architecturally similar cousins has, with enough work on the JVM, achieved nearly equivalent execution speed.

Does anybody know where we are with Javascript now? Traditionally, its performance has been pathetic, since it wasn't all that heavily used; but of late competition to have a better javascript implementation has been pretty intense. Is there anything fundamentally wrong with the language, that will doom it to eternal slowness, or is it on the trajectory to near-native speeds eventually?

Re:Pardon my ignorance(and I don't want a holy war

[NoSig]

Java isn't a dynamic language which is the central difference that makes languages like Javascript and Python much slower than C++ and even Java with the compiler technology as it is now and for the forseeable future. A big still relevant problem with Java is the long loading times you end up with starting up large applications. Javascript isn't even compiled to bytecode so that problem would be much worse if big applications were written and run as Javascript. Javascript is getting faster all the time but don't expect anything like C++ or even Java for general purpose programming. Which is fine because that isn't what Javascript is all about.

Re:Pardon my ignorance(and I don't want a holy war

[fuzzyfuzzyfungus]

Given that browsers tend to cache website elements, for better speed when loading objects that haven't changed since last load, and given that, while people want their page now, their computer usually has a fair amount of idle time available, would you expect to see browsers implementing some sort of background optimization mechanism that chews over cached javascript during idle periods in order to reduce the amount of computationally expensive work that needs to be done should the page be reloaded? Or is Javascript not amenable to that level of preemptive processing?

Re:Pardon my ignorance(and I don't want a holy war

[thoughtsatthemoment]

There are indeed a few fundamental issues with Javascript that make it both useful for coding and at the same itime hopeless toreplace something like C.

In javascript, accessing the property of an object requires a lookup, and some checking to make sure things exist. Compared to accessing a field in a C struct, that's a lot of overhead (AFAIK, google does do heave optimazation in this area). The reason for doing that is for safety and being dynamic.

In a large application, ultimately performance comes from memory management. The best way is using memory and resource pooling, fine tuned by the programmer. I doubt javascript can be efficiently used this way. I don't think javascript can be used to code Word or a browser (I mean the browser itself) any time soon.

Multithreading is also an issue. There is not really anything wrong with the language. It's more of an implementation issue.