Faster?
Let's hope it doesn't get its speed using 100% CPU on all cores.
Mozilla has claimed the fastest SunSpider scores on the planet, after internal tests showed that its latest Firefox JavaScript engine — which includes the new JagerMonkey extension — outperforms both Google Chrome's V8 engine and Apple Safari's Nitro. Director of community development Asa Dotzler made the claim on Monday …
but (apart from Google Wave and looping code) I've not had any JavaScript speed problems - except when running speed tests.
Any slow JavaScript seems to be down to the cross site calls, something that can only be speeded up with noscript blocking or similar - the fastes machinein the world can seem to speed up google analytics or some crap advertising implant.
Even my own browser based code editor that I know contains lousy code works well enough on my old Duron based test machine.
Casual browsing may not have many instances of javscript bogginess, but in the world of rich browser applications, javascript can have many bottlenecks. I'm aware of a browser-based game that uses javascript extensively for "world map" data and image placement, client-side html generation, etc (basically everything between <body> and </body>) and it runs terribly under IE8 (obviously) but plays tolerably under FF3.6. Speeding up Javascript will only make these things more commonplace, requiring faster javascript execution, enabling more..etc.etc...
It is important to remember on most websites that without user interaction the content is largely static. Typically things only happen when a) the page is first loaded, or b) the user does something like mouseover or click on an element which has attached JS. When either of these things happens, the performance of is affected by JS, DOM, CSS, rendering API, layout, native event model, operating system, context switches etc.
JS is an important component in this performance but in many cases the browser would spend a lot more time in the layout engine or the DOM code. The JS would just be a little glue which creates an element and sticks it in the document, or twiddles an attribute etc.
Running from the shell is still a good test since it eliminates the other noise. I expect in practice that improving the JS engine would result in subtle improvements. The biggest winner is probably the browser itself since Firefox uses a lot of JS in its UI. Sites that drag in a lot of JS during startup (e.g. GWT, Dojo etc.) probably benefit a lot too.
I don't know about anybody else, but I've never really had any browser speed problems. And if I had I don't think the tiny lead that Firefox now has over the competition (until next week, no doubt) would induce me to change.
Indeed it is such a tiny advantage that I can't believe Mozilla are shouting about it. Basically the advantage is so small that all three browsers are, in effect, at the same level. As such Mozilla are basically saying "Look how great we are, we've caught up with the competition and we're just as good as them now." Not much of an advertising coup is it? "Buy a Vauxhall, it's just as good as the competion in some areas."
is less of an issue than other factors in the environment. Only time mine is slow is when it is waiting for one of the damn Facebook.static pages to finish uploading its data to my pc. And I'm running the current standard install for FF, not the beta.
Mozilla has broader aspirations than running javascript trinket animations quickly. They envision that a more powerful javascript will lead people to writing more heavy duty programs in javascript to run in the browser.
Take a look at their new and developing benchmark. Rather than running a couple dozen little code snippets dozens of times, many of which are done in a few milliseconds, their benchmark contains some long running javascript tests, like realtime image processing. In that context, the tracemonkey approach does better as it pays to invest more time in the compile and buy it back in the runtime. For their selected set of benchmarks, they are twice as fast as the others.
"This new method JIT compiler uses the Nitro assembler from Apple’s open source WebKit project, the same assembler used by Google Chrome and Apple Safari."
In other words, Mozilla couldn't beat them, so they joined them!
(not that there's anything wrong with that, but we're now down to only three assembers for javascript - SquirrelFish/Nitro, Carakan and Chakra)
most guys running a new pc will have no problem I guess - but those on a budget, with an old P4 will notice how sluggish FF is against Opera - you dont need benchmarks to see it!
the big problem with Opera, is the bad attitude of the managers - they remove good features that very old users love, and when we complain, they just ban us for disturbance!! this and a refusal to build in website compatibility or aggressively advertise, is why it stays almost unknown or given a bad rep...