Slashdot Mirror
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."
Excuse me, but I think that Tracemonkey is actually faster than V8. Has Tracemonkey really fallen that far behind in two weeks?
Firefox 3.1 (pre-release) uses less memory than Firefox 3, which uses less memory than Firefox 2. Compiled javascript takes a tiny fraction of the total memory used by a web browser. The vast majority is uncompressed bitmaps and string fragments.
Why? Does apple even sell those anymore?
Once you start despising the jerks, you become one.
There are very few popular sites that are too slow, because web developers do not like to make slow sites. If a web developer does make a slow site, it doesn't become popular because users are too impatient and go to faster ones.
That's really the whole point of the recent focus on JavaScript performance. Web developers want to make complex sites to support the features the users want, but they cannot because all those features make the sites too slow. Google especially wants to develop a web-based Office-killer suite. That's why they developed Chrome with a very fast JavaScript engine, minimal chrome to make web apps more like local apps, and put each tab in a separate process so you can kill those memory- and CPU-hungry sites when you need to.
What a fool believes, he sees, no wise man has the power to reason away.
Yeah, except that it's JavaScript, traditionally one of the slower languages because it's objects are basically hashtables. The improvements you see are going to be mostly to fastpathing past those hashtables. This unfortunately means that the improvements you see in JavaScript are unlikely to port to other languages since those improvements are to a feature that isn't used in most other languages. (Lua and Python may be exceptions.)
Mostly correct. Netscape made money selling their horrid web server in corporate environments. They were giving the browser away for free for non-commercial users. If the truth were told, back when Netscape was a relevant browser, most of my coworkers were grabbing the free, non-commercial version and installing it at work. And Netscape didn't really care, as they were giving away their browser in order to drive sales of their server. Netscape's server arm survived for a loooong time, finally becoming the basis for Sun's application server. IIRC, only the newest version of Sun's app server (i.e. 9.x aka GlassFish) doesn't directly trace it's roots to Netscape/iPlanet. And let's not forget Netscape Directory Server. Or, as it's known today, RedHat Directory Server. During the dot-com era, it was one of the better LDAP implementations.
You should take a look at http://cappuccino.org./ Is really interesting and brings the best of both worlds.
JavaScript isn't single-threaded.
Only one JavaScript thread is used by firefox (and maybe other browsers -- I don't know).
In fact, spidermonkey is thread-safe and you can run multiple JavaScript threads outside the confines of the browser. In fact, I have written a class for spidermonkey which lets you create real OS threads running JavaScript functions.
> 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
Out of curiosity, how many programming languages do you know that will let you keep executing code once a syntax error has been reached, or an exception has been thrown but not caught?
The problem here isn't language design, it's poor programming. And try..catch block will work wonders around other-peoples-crappy-code.
> 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.
Aside from function.arguments and === in JavaScript 1.2, I'm having a hard time thinking of a JavaScript language change which was broke backwards compatibility. That includes IE. Although it would be nice if IE would fix their stupid [1,2,3,].length bug.
Do daemons dream of electric sleep()?