Revamped WebKit JavaScript Engine Doubles In Speed

Shin-LaC writes "In a post on their official blog, WebKit developers introduced the 'next generation' of their JavaScript engine, SquirrelFish Extreme, claimed to be twice as fast as its predecessor. The post lists several changes contributing to the performance improvements, including 'bytecode optimization,' a 'polymorphic inline cache' (which sounds similar to V8's 'hidden class transitions'), and a 'context threaded JIT' compiler which generates native code (currently only for x86 processors), and is also applied to regular expressions. The new JavaScript engine is already available in the latest WebKit nightly builds. According to comparative benchmarks, the new engine is around 35% faster than the V8 engine recently introduced in Google Chrome, and 55% faster than Mozilla's TraceMonkey."

Comments

Re:That's great!

[caffeinemessiah]

The next revision of SquirrelFish, said to make Javascript not suck anymore, is due to be released in 2048.

I know you're just trolling, but Javascript is actually getting fun to program in for recreational purposes. It reminds me of assembly programming back in the day, at least that's where its development seems to be in terms of a programming language. It's actually fun to hack, and you can already do some nifty things like pseudo-threading using its window.setTimeout() function and some clever programming. The fact that the engines are getting more powerful just makes it more fun and likely to pay off.

I remember when C/C++/ASM programming was fun to hack, until the age of monolithic libraries like MFC and OWL (and now things like the JDK and .Net) came and ruined that fun by restricting your freedom. If there's one thing that will make me buy into the whole browser-as-OS thing, it's an efficient, bare-bones and flexible Javascript implementation, kind of like programming in C for your browser.

Javascript

[Lord Byron II]

You know, 5 years ago, if somebody had asked me about Javascript, I would have told them that it was a dying technology. At the time, it seemed that it was only used for pop-ups and advertisements. Back then, I had it turned off in all of my browsers. Now, we rate browsers based on their Javascript performance... amazing.

Re:Javascript

[PietjeJantje]

I would go a little further than that, realizing this is difficult to swallow for many following the javascript/ajax bashing meme here on Slashdot for so long, but in their desire to snub it as something "real" software engineers wouldn't touch (or is it fear of change from an aging community?) the clear reality IMHO is that javascript is taking over the role on the client side that java was supposed to be, and it is to be the platform for Google and such to compete against MS on the desktop. You can choose to ignore that, but I doubt it's a good career move, especially considering some of the powers behind it, pushing the technology. Kids today, where they used to make MS apps, they now make apps for the browser. MS is shitting its pants by hanging on to a non auto-update of IE6, while IE8 seemingly will sabotage canvas and whatever it can target. They can't keep behind forever with IE6, so it seems the strategy with IE8 will be to battle all that with Silverlight, working best on IE8 of course, to keep the audience on the MS world. I wouldn't underestimate them either whatever you think of that strategy, for the mere fact 25% still use IE6 and seem to be in their hands to start with.

Re:Javascript

[RAMMS EIN]

``I would go a little further than that, realizing this is difficult to swallow for many following the javascript/ajax bashing meme here on Slashdot for so long, but in their desire to snub it as something "real" software engineers wouldn't touch (or is it fear of change from an aging community?) the clear reality IMHO is that javascript is taking over the role on the client side that java was supposed to be,''

Speaking as someone who isn't entirely happy with the direction JavaScripts have taken since the invention of the term "AJAX", perhaps I can shed some light on that. I can't speak for the entire "aging community", but there are bound to be some people who agree with my opinions.

First of all, calling AJAX bashing a meme is somewhat misleading. I did not speak out against it because it was a meme, I spoke out against it because I had actual technical and philosophical objections. Some of that is emotional: I resent the hype around AJAX. It wasn't actually new; I have been doing stuff like that since 1997 or thereabouts. Where's my recognition? But, the grumpiness of an old man aside, let's look at the technical aspects.

Many modern, cool websites try to use JavaScript, HTML, CSS, and HTTP to create user interfaces that resemble those of desktop applications. These web technologies were meant to support a request-response model, where each response is essentially a static page. Using JavaScript and CSS, developers create the illusion that it isn't a static page, but a dynamic environment with windows, buttons, menus, popups, anymation, smooth transitions, interaction, etc. In other words, an environment that is nothing like how the web used to be. To support this illusion, heaps of JavaScript are piled on disfigured HTML, and HTTP requests are abused to send what should be small pieces of data to and from the server.

In the process, compatibility is thrown out of the window - don't try to view any of those pages with an unsupported browser, and don't try to analyze the page with a web spider; you will only end up with garbage. Even if you have a supported browser, you will need a pretty powerful computer to get anywhere near decent responsiveness from what are really very primitive user interfaces. This is why I have opposed the wave of AJAX websites. It's not that I don't think the things that are being built with it aren't cool. But they are being built on the wrong technology, which yields suboptimal results and, at the same time, inhibits the adoption of what would be the right technologies. I am happy to see fancy interactive applications being built on open standards, rather than on proprietary technology, but I would rather have it be built on standards that were designed for it, rather than breaking existing standards to get something that sort of works, if you have a fast computer and the right browser. And yes, I do regard any HTML that can't be usefully processed by a search engine or screen reader as broken.

All this is is nothing against JavaScript. I think JavaScript is a nice language, and I am happy to see we're finally working on creating implementations that aren't dog slow. Perhaps we can also add some useful features...for example, raw sockets, so that we don't have to occur the overhead of a full HTTP request any time we wish to communicate with another system. And perhaps we could actually standardize APIs to functionality like native widgets (how is XUL these days?) and drawing functions (something like Cairo, perhaps?). Then we would have a platform that is actually good for interactive applications. Throw in some support for libraries (with caching and versioning) so that not everything needs to be reloaded all the time, and it's starting to look like a very workable solution.

You see, I am not opposed to change ... I am opposed to changing in a direction we know isn't very good, when we know how to make it better.

Re:Javascript

[PietjeJantje]

In the process, compatibility is thrown out of the window - don't try to view any of those pages with an unsupported browser, and don't try to analyze the page with a web spider; you will only end up with garbage. Even if you have a supported browser, you will need a pretty powerful computer to get anywhere near decent responsiveness from what are really very primitive user interfaces. This is why I have opposed the wave of AJAX websites.

While there's substance to most of your arguments, you -are- getting old, I'm afraid. It reminds me of times when one was flamed for using C over assembly. It reminds me of the time when I was a student and Mosaic 0.9b was released, and it was a non-event because of the above sentiment: slow, resource hungry, and in a time when it was undone to send sigs over 4 lines not regarded a good thing.

In the meantime the world will move on, javascript already got great cross-browser libraries that make sure it works from IE6 to webkit, and data exchange will be unhyped and improve over time. But no, you can no longer view it on Lynx, and the web -will- be expanded from the dom/request&response model to a dom+javascript (the natural companion) model with more sophisticated means of data exchange. It's a development the noscript-ers can forget they can stop it. It's not like accessibility is not important though, this is an area of development and research as well. Google wants to be able to index that. Also, it's not a xor situation. Google's search pages work on everything. For their apps you need javascript. It's just an extra option (sure it's abused for badly degradating bling - but the web will always be 99% pulp). On the interface site I don't expects any standards soon, but the improvements of the APIs of the big players are big from version to version.

I think you'll be surprised how good and smoothly it will work and already can work if you look for the right examples. It's easy to have formed an opinion on this stuff a while back and freeze it (especially as you can always choose and pick from millions of examples of bad implementations or use), and mine would have been roughly the same. First of all, I'm a nut for graceful degradation. And I hate those first gen web office apps, all with their scruffy custom interfaces, endless ajax loading indicators, curvy orange and cyan "look how cool I am" cliches involving the marketing term web 2.0, and in general wanabee behavior which makes you think "why? WHY on earth do it in the browser", and "oh noo, not reinvent the wheel again by taking steps backwards". Forget that. It's moving on, and soon all your objections will be as relevant as someone who says you should use assembler over C or even C over Python.

Sure, now with anecdotal evidence!

[martinw89]

I have Opera 9.5 and FF 3 on my Ubuntu system. There is a noticeable difference in rendering speeds for JS medium-heavy websites between them, Opera being slower. Now, I had no idea of Opera's relative speed when I noticed this. So I tested them with Sunspider and surely enough there was a good gap between both, with FF 3 being much faster in benchmarks.

NB: I'm not being anti Opera. Opera is awesome, even though it's not my primary browser. I'm just saying you can notice the difference in slower JS engines.

Re:Message to Google

[Darkness404]

If anyone has clout and interest in this, it'd be Google. I'm sick of responding to dialog boxes from cookie setting, noScript, etc.

Simple answer. Stop being so paranoid. Just allow all first-party cookies, have a decent /etc/hosts file that blocks ads and use Linux/OS X/Any OS other than Windows and you are basically safe from any major malware outbreak. I've tried noScript and found it to be more of a pain then it was worth. Sure, it might make you less secure, but honestly, I run Linux and even though it is possible to hack a Linux box, most script kiddies won't bother.

Google doesn't care about you, the .01% of the internet that doesn't just accept scripts and cookies.

Amazingly, everyone is faster than everyone else

[zoips]

Chrome/V8 is faster than Firefox/Tracemonkey. WebKit/SquirrelFish Extreme is faster than Chrome/V8. Firefox/Tracemonkey is faster than Chrome/V8. And around we go, always twirling, twirling, twirling towards freedom.

Re:Faster = more memory?

[hairyfeet]

I know this is going to be labeled troll,but frankly I don't care. Why is everybody tripping over themselves trying to make faster and faster JavaScript,when the security sucks? I have been able to cut down my customers infections by a good 80% just by installing Noscript and teaching them how to use it. Every day we see more and more JavaScript exploits out in the wild,and yet the only thing anyone seems to be concerned with is speed? JavaScript is getting as bad as ActiveX was in its heyday,and Noscript and sandboxing is really only adding a bandaid to the bleeding wound.

We need to look at how JavaScript is used on the web and find new ways to lock it down and make it more secure. If we don't,mark my words,it will be talked about in 5 years just like ActiveX. Sounded like a good idea at the time,and then the malware ruined it for everybody. But as always this is my 02c,YMMV

Why not use a JVM?

[Montreal]

It's been possible to run JavaScript on a JVM for some time now (based on Mozilla's Rhino). Does anybody have any numbers as to how these recent in-browse JavaScript optimisations stack up against 10+ years of Sun work on general virtual machine optimisation? Could it be faster just to fire up the Sun JVM and use that as the JavaScript engine?

Re:That's great!

[Waccoon]

It's actually fun to hack, and you can already do some nifty things like pseudo-threading using its window.setTimeout() function and some clever programming.

I had to do this, because JavaScript is single-threaded.

A Java applet I need to support kept trying to make a JavaScript call to the browser, and kept failing, which crashes a background timer I had implemented in JavaScript. I had to "restart" JavaScript using a mouseover event and use threading to keep it from using up all the CPU time. It was such a stupid hack, but it worked.

I eventually figured out the function name the applet kept calling and was able to shut it up. It still boggles me that any JavaScript from anywhere, such as from an ad, can crash the language and leave you with no JavaScript support at all. It's very hard to count on a language when browsers implement is so badly, especially when you have no choice but to support really old software that keeps doing bad things that upset newer, stricter versions of a scripting language.

Now, does this WebKit update fix the JavaScript threading issue? Then I'll be impressed.