Slashdot Mirror

← Back to Stories (view on slashdot.org)

Next-Gen JavaScript Interpreter Speeds Up WebKit

Posted by timothy on from the zippity-zappity dept.

JavaScript is everywhere these days. Now WebKit, the framework behind (among others) Safari and Safari Mobile, as well as the yet-unreleased Android, is getting a new JavaScript engine called Squirrelfish, which the developers claim provides massive speedups over the previous one. The current iteration of the engine is "just the beginning," they claim; in the near future, six planned optimizations should bring even greater speed. With JavaScript surviving as a Web-page mainstay despite many early gripes, and now integral to some low-powered mobile devices, this may mean many fewer wasted seconds in the world.

8 of 193 comments (clear)

  1. The real question is.... by AKAImBatman · · Score: 4, Interesting

    ...how does this compare to Tamarin? With Javascript running for longer periods of time, a runtime-optimizing JIT seems to make a lot of sense. SquirrelFish's optimized bytecode engine sounds interesting, but I can't help but feel that it's going to fall short in the next-gen race for Javascript performance.

    Of course, anything that improves JS performance in browsers (making some of the libraries faster and/or hardware accelerated always helps... hint, hint!) is a win for the consumer. And from that perspective this sounds very interesting. :-)

    --
    Javascript + Nintendo DSi = DSiCade
    1. Re:The real question is.... by Anonymous Coward · · Score: 5, Interesting

      It feels like Safari is moving so incredibly quickly. Webkit 3.1 already felt around twice as fast as webkit 3.0 in terms of javascript execution; now SquirrelFish is around one and a half times as fast again... in what's basically its first stable implementation. And they're already targetting optimisation points, and it's already caught up to Tamarin (and iirc webkit 3.1 is at least on par with firefox 2/3). Absolutely amazing.

      The iPhone is the one to really benefit from this, because it's where the pauses are currently noticeable.

      And IE really, really suffers in comparison. Microsoft has to be wincing about all this, if only for pride's sake... I'd love to see speed improvements to IE 8 beyond the what's known already, though the DOM speed improvements will help a lot for parity.

    2. Re:The real question is.... by samkass · · Score: 4, Interesting

      According to the article the Windows version of SquirrelFish aren't as optimized as the Mac and Linux versions because of some API dependencies, although I haven't seen any benchmarks.

      --
      E pluribus unum
    3. Re:The real question is.... by cryptoluddite · · Score: 4, Interesting

      they began by interpreting everything, but if you spent a lot of time executing a part of the code, it will aggressively optimise it. The newer Java VMs do the same thing. Newer as in since 1.2... ten years ago.

      I have to disagree with you about Smalltalk. Before it in performance are LISP and on the great benchmark shootout even LuaJIT (!) is faster than VisualWorks smalltalk -- vw is pretty fast for a smalltalk. Smalltalk has been optimized a lot, but it's not really a 'fast' language.

      For most JavaScript, this is a complete waste of time. It is very rare for JavaScript to run for more than a fraction of a second at a time and so latency caused by interrupting execution much worse than just running it slightly more slowly. The ActionScript VM in Flash is very different, since it is designed to run scripts that stay running for minutes at a time and are fairly CPU intensive. JavaScript will be the main programming language in the next decade at least, imo, and improving execution speed of JavaScript is never a waste of time. The faster it is, the more it will be used.
  2. Re:squirrelfish? by Anonymous Coward · · Score: 4, Interesting

    squirrelfish? What's next? rabbitelephant? curvaceous coelacanth? fishfishfishrabbitfish? We desperately need an automatic "hip open source software name generator" before someone gets hurt.

    Usually what happens is a development team uses themed codenames to easily distinguish product versions. In this case, they're probably using fish names. I worked somewhere with the same theme. We had all sorts of fish names and eventually they got a bit wacky (aquaman). The problem is when in OSS or other open development models, those names become public instead of a properly chosen name. With OSS, this happens because name recognition builds up as people discuss the unfinished software. We only had this happen once, where Man-O-War was demoed for the defense department and they liked the name so much we had to keep it for PR reasons.

  3. Re:plug-and-play javascript engine by Daniel+Dvorkin · · Score: 4, Interesting

    It's the old "modular vs. monolithic" argument -- do you write your app as a bunch of small pieces that all communicate through some standard protocol, so you can swap them in and out and upgrade them at will, or do you make everything tightly coupled and interdependent? Browsers, like most apps, tend to go back and forth on this, because there are real advantages and disadvantages to each approach (and most apps end up meeting somewhere in the middle.) Every few years someone comes along with an idea that promises to Revolutionize! Programming! by making everything modular and completely independent, and everyone gets all excited about it and plays with it for a while, and then comes to the conclusion that if it works, it's still too slow. The good ideas that come out of these Revolutions! In! Programming! get absorbed into the mainstream (e.g. OOP, and to some degree microkernels) but they never seem to take over completely.

    --
    The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
  4. Re:Javascript grows up by jamshid · · Score: 5, Interesting

    This was a really interesting article about the kind of optimizations javascript is getting. Btw, it still amazes me that after the GUI class library wars of the 90s, and all those Java ui frameworks in the early 2000s, "javascript over http" is state of the art in human-computer interfaces. Anyone who would have accurately predicted this future would have been labeled a madman.

    http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

    "Why JavaScript? Well, it was Ajax. See, what happened was... Lemme tell ya how it was supposed to be. JavaScript was going away. It doesn't matter whether you were Sun or Microsoft or anybody, right? JavaScript was going away, and it was gonna get replaced with... heh. Whatever your favorite language was.

    I mean, it wasn't actually the same for everybody. It might have been C#, it might have been Java, it might have been some new language, but it was going to be a modern language. A fast language. It was gonna be a scalable language, in the sense of large-scale engineering. Building desktop apps. That's the way it was gonna be.

    The way it's really gonna be, is JavaScript is gonna become one of the smokin'-est fast languages out there. And I mean smokin' fast."

  5. Still seems slow... by Jon+Abbott · · Score: 5, Interesting

    I just loaded the latest nightly of WebKit, which from what I gather is supposed to be using Squirrelfish, but it still seems to run the "Wundermap" at wunderground.com more slowly than Firefox 3.0RC1. I consider the Wundermap to be the ultimate browser test, as it has to process so much JS and images... I recently tried running it on a Mac Pro 8-core at the local Apple store, and it still loaded slowly! The Mac Pro absolutely flew through everything else I threw at it, including playing multiple HD movies at the same time, but when loading the Wundermap, it is almost as slow as my puny 2.0 GHz G5.

    --
    Slashdot's first reaction to VMware