Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Technology (Apple) Java Programming Software Technology

Revamped WebKit JavaScript Engine Doubles In Speed 270

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."
This discussion has been archived. No new comments can be posted.

Revamped WebKit JavaScript Engine Doubles In Speed

Comments Filter:
  • by Anonymous Coward on Friday September 19, 2008 @07:57PM (#25080399)
    As you can see in this bar graph, our bar is bigger than our competitors' bars.
  • The next revision of SquirrelFish, said to make Javascript not suck anymore, is due to be released in 2048.

    • Re:That's great! (Score:5, Interesting)

      by caffeinemessiah ( 918089 ) on Friday September 19, 2008 @08:11PM (#25080537) Journal

      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.

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        ... 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.

        Bullshit.

        • Re:That's great! (Score:5, Insightful)

          by STFS ( 671004 ) on Saturday September 20, 2008 @08:25AM (#25084093) Homepage
          Please mod parent up, it's true, this is bullshit! Monolithic libraries in C++ restrict your freedom? How in the world do you get to that conclusion? FYI, almost nobody uses MFC, and if it bogs you down, well duhhh... don't use it! C++ is almost exactly the way it used to be, the language hasn't changed at all. You can still do everything by hand like you used to if that's what you want. The "monolithic" libraries you speak of tend to help the rest of us get things done and I for one, welcome a more diverse selection of these.
      • Re: (Score:3, Interesting)

        by phantomfive ( 622387 )
        OK, I know you're going to call me a fanboy, but you really need to try Cocoa. MFC is miserable not because it's monolithic, but because it's designed in a way that makes everything miserable. .Net is a little better, but still not fun.

        Cocoa (really NextStep) makes it easy to take control of whatever part you want: it is logically organized and easy to customize any part. Do you want to make a window that covers the whole screen transparently, then lets you draw on it? Simple, and it's programmaticall
      • Re:That's great! (Score:5, Insightful)

        by try_anything ( 880404 ) on Saturday September 20, 2008 @02:48AM (#25083039)

        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.

        How do libraries and application frameworks restrict your freedom? Your boss makes you use them? Sorry, I don't follow your argument at all. If you want to write your own socket library, regular expressions library, and logging framework, go ahead and do it. Nobody's stopping you.

        If modern amenities have made you bored with programming, I suggest attacking a problem domain that hasn't yet been made trivially easy. Get a four-core box and convert a single-threaded application into one that uses all four cores efficiently. That's something that Java and .NET won't solve for you. Whenever one problem is rendered trivial by Moore's law or by some helpful library author, there is always a bigger problem to tackle.

      • Re: (Score:3, Interesting)

        by Waccoon ( 1186667 )

        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 Java

        • Re:That's great! (Score:5, Informative)

          by multipartmixed ( 163409 ) on Saturday September 20, 2008 @06:06AM (#25083617) Homepage

          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.

    • Re:That's great! (Score:4, Insightful)

      by Niten ( 201835 ) on Friday September 19, 2008 @09:04PM (#25080995)

      I had a feeling someone would use this as a JavaScript-bashing opportunity. After all, JavaScript is the world's most misunderstood programming language [crockford.com].

    • Re: (Score:2, Funny)

      Python3000 will, like, totally kick SquirrelFish2048 in its furry scales.
  • by martinw89 ( 1229324 ) on Friday September 19, 2008 @08:04PM (#25080475)

    Excuse me, but I think that Tracemonkey is actually faster than V8 [mozillazine.org]. Has Tracemonkey really fallen that far behind in two weeks?

  • One of the things we've seen in the past few releases of any browser is that new features seem to increase the already monumental footprint of current web browsers. As far as I've seen, JIT compilers use a whole freaking lot of memory. While I suppose this is acceptable for the whole "Web 2.0 means the web is the only useful thing on your PC!" crowd, I'd like to have a few (3 or 4)browser tabs open while I'm playing a game, for example, without the browser killing my gaming experience.
    • by martinw89 ( 1229324 ) on Friday September 19, 2008 @08:20PM (#25080615)

      No, I will not get off your lawn. Space/speed is a tradeoff. At the moment, we have even bottom of the barrel desktops selling with large amounts of memory. With the eventual rise of 64 bit, expect the amounts to go up even more. There's no reason to avoid taking advantage of this. What's the point of having this huge (seriously, look at the memory difference from now and 10 years ago) amount of memory to just let it sit there, save the occasional multimedia editing task?

      As for your game, it seems to be using quite a huge chunk of memory as well. You know, one of the things we've seen in the past few releases of any modern 3D game is that new features seem to increase the already monumental footprint of current games. And hell, I'm using my browser at least 10 times longer a day than I'm playing a game. I want my browser to be snappy, I don't mind not visiting Super Ultra JS Web App 3.6 if I'm going to be playing a resource intensive game. In fact, I probably wouldn't be using my browser at all anyway.

      But that last paragraph is just my personal experience, YMMV

      • Re: (Score:3, Interesting)

        by hairyfeet ( 841228 )

        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 a

        • Except that a lot of speed gains are accomplished by starting over with a modern engine design, meaning the engine code is all written in the security-aware era.
        • by jsebrech ( 525647 ) on Saturday September 20, 2008 @07:51AM (#25083965)

          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?

          Those aren't javascript exploits, they're security issues in other parts of the code that are easiest to trigger via javascript, and that you will resolve with proper sandboxing, which all browser makers are working on. Exploits in pure javascript are pretty rare.

          I think we're talking about a trade-off between usefulness and security anyway. Disabling javascript to gain security is a bit like putting foam on the end of a hammer to avoid hurting your thumb. It sort of misses the point.

        • JavaScript in Firefox is (almost?) never the source of security problems in the real world. If Noscript stops something is only because an exploit in another component also uses JavaScript (and often only because the person writing the exploit code was lazy).

          Try disabling Java and deinstalling Flash and all the plugins (or at least using Flashblock) and Adblock Plus+Easylist. You will achieve exactly the same results.

          I'm a web developer and I'm asking to please don't disable JavaScript. It's not a secur

    • by Jeffrey Baker ( 6191 ) on Friday September 19, 2008 @08:25PM (#25080645)
      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.
    • by Anonymous Coward on Friday September 19, 2008 @08:38PM (#25080775)
      Anyone using the term "gaming Experience" deserves to have it ruined.
    • Re: (Score:3, Funny)

      by MightyYar ( 622222 )

      One of the things we've seen in the past few releases of any browser is that new features seem to increase the already monumental footprint of current web browsers.

      It's somewhat mitigated by the appropriation of other tasks. For instance, in 1994 I'd run a copy of Eudora, a copy of Netscape, and a copy of a word processor on my Centris 650 with 8MB or RAM. But now, I can do all of these things in my web browser - so it's okay if it takes a little bit more RAM. And to think that people decried Netscape Suite for taking on too much!

      Here, let me fire up my Activity Monitor app and see what Firefox is... SWEET JESUS! 366 MB!!! OH MY FUCKING GOD, WHAT HAVE WE BECOME???

      • Re: (Score:2, Troll)

        by Klaus_1250 ( 987230 )
        Run one of the Javascript benchmarks in a browser and you'll be surprised how much memory your browser can eat up. I've seen Firefox @ 450MB and Chrome @ 600MB, just by running some heavy Javascript code. While the speed increases are great, 500MB memory usage for just a browser is a lot.
  • Competition (Score:4, Insightful)

    by Per Wigren ( 5315 ) on Friday September 19, 2008 @08:12PM (#25080541) Homepage

    This is a wonderful example of what happens when there are open standards and healthy competition! The consumer is the winner!

    • by TubeSteak ( 669689 ) on Friday September 19, 2008 @08:25PM (#25080643) Journal

      This is a wonderful example of what happens when there are open standards and healthy competition! The consumer is the winner!

      Is that why /. "consumers" mostly use NoScript?
      Malware: Now 35% faster.

    • Re: (Score:2, Insightful)

      by willyhill ( 965620 )

      I hear even Microsoft is getting into the game with IE8, supposedly the script engine on that one is much faster than the IE6/7 one, almost on par with FF2.x.

      Long gone are the days of stagnation. Competition is good, let's embrace it and be happy about it instead of complaining (as some people seem to be doing here) about the memory footprint and whatnot.

      Maybe soon the browser will become a viable platform for application delivery, which Netscape promised us back in the early 90s.

  • Mmm... (Score:5, Funny)

    by actionbastard ( 1206160 ) on Friday September 19, 2008 @08:13PM (#25080555)
    'bytecode optimized polymorphic inline cache'.
  • by Tragek ( 772040 ) on Friday September 19, 2008 @08:15PM (#25080581) Journal

    I really am loving this JS engine war; I don't program JavaScript, and know nothing about JIT, but having read more than my fair share of compiler optimization and analysis papers, it's really good to see that compiler tech and research is alive and kicking.

    • by mdmkolbe ( 944892 ) on Friday September 19, 2008 @09:51PM (#25081345)

      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.)

      • Re: (Score:3, Insightful)

        Yeah, except that it's JavaScript, traditionally one of the slower languages because it's objects are basically hashtables.

        And php stores its variables.... how?

  • Javascript (Score:5, Interesting)

    by Lord Byron II ( 671689 ) on Friday September 19, 2008 @08:16PM (#25080589)
    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 (Score:4, Insightful)

      by MightyYar ( 622222 ) on Friday September 19, 2008 @09:15PM (#25081101)

      it seemed that it was only used for pop-ups and advertisements.

      No, no... it was also used to invade your privacy.

      • it seemed that it was only used for pop-ups and advertisements.

        No, no... it was also used to invade your privacy.

        was???

      • by galego ( 110613 )

        exactly ... *was* ... **is** ... and will be able to do so even faster now. ... and the organized crime folk probably didn't even have to fork over a penny.

    • Re:Javascript (Score:5, Interesting)

      by PietjeJantje ( 917584 ) on Friday September 19, 2008 @10:35PM (#25081657)
      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 (Score:5, Interesting)

        by RAMMS+EIN ( 578166 ) on Saturday September 20, 2008 @08:48AM (#25084203) Homepage Journal

        ``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 (Score:4, Interesting)

          by PietjeJantje ( 917584 ) on Saturday September 20, 2008 @09:38AM (#25084459)

          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.

    • by Have Blue ( 616 )
      It's even more ironic that you have Microsoft to thank for that. They were the ones who originally came up with the XMLHTTPRequest object that made interactive Javascript applications actually useful.
  • by pizzach ( 1011925 ) <pizzach.gmail@com> on Friday September 19, 2008 @08:34PM (#25080723) Homepage
    Why? Does apple even sell those anymore?
    • And Bill Gates still shows up for MS stories and he's retired. Granted he's doing commercials now, but that's about it.

      They're kind of iconic and nostalgic in a way. Sure it's only been a few years/weeks, but in the tech world that may as well be eons.

      Besides, the editors can't even be bothered to spell check story summaries or make sure they're factual. What makes you think they'll take the time to update the story icons?

    • Re: (Score:3, Interesting)

      by hansamurai ( 907719 )

      Not to mention the cup of coffee with the alt tag "Java" representing a javascript story.

    • by toby ( 759 ) *
      But plenty of people still use them.
  • by Graywolf ( 61854 ) on Friday September 19, 2008 @09:28PM (#25081185)

    Between TraceMonkey and SquirrelFish, "V8" seems so... weird. They better give it s regular, modern name like ThreadMole or SkunkAmoeba.

  • by zoips ( 576749 ) on Friday September 19, 2008 @09:51PM (#25081343) Homepage
    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.
    • Only one way to settle this, a shootout [debian.org]. Spidermokey is already on there. Get the rest of them up. (I'd get V8 up except it's missing command line arguments [google.com].)
    • Re: (Score:3, Insightful)

      by BZ ( 40346 )

      Bingo. What it comes down to is that the answer to "Is X faster than Y" will depend on two things:

      1) The benchmark
      2) The day of the week (or the exact, to the minute builds you're testing, if you prefer)

      The reason for the latter is that all three are in active development. Each one is doing measurements right after landing major changes, against whatever the current state of the other two is. That means that there is inherent bias there in favor of whoever is doing the measurements being fastest: they'

  • 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.

    If you remember [mozillazine.org], TraceMonkey was benched to be faster than V8, Brendan Eich said: "We win by 1.28x and 1.19x, respectively. Maybe we should rename TraceMonkey "V10" ;-)."

    And now somehow Safari beats TraceMonkey by 20% more than it beats V8. Funny that.

    Those benchmarks are useless.

  • Why not use a JVM? (Score:4, Interesting)

    by Montreal ( 594947 ) on Saturday September 20, 2008 @04:02AM (#25083257)
    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?
  • by dwarfking ( 95773 ) on Saturday September 20, 2008 @08:34AM (#25084125) Homepage

    Do any of the engines mentioned in these postings offer a clean way of using JavaScript as a standalone engine for non-browser applications?

    I don't want a Java based one (don't want the JVM). I'm trying to compile V8 alone but the code has issues right now if you don't use VC++. I've tried SpiderMonkey in the past but that code is just difficult to follow.

    Interestingly under windows the WSH (Windows Scripting Host) can work with either JavaScript of VB script. The engine allows the JavaScript code to access many of the Windows objects.

    I'd like to see a JavaScript engine with pluggable modules (sort of like TCL) and possibly a nice accessible GUI (like TK).

    Any suggestions on which engine is best to use as the standalone interpreter with the easiest extensibility?

    • Re: (Score:3, Informative)

      I know nothing of WebKit, so I will not speak of it.

      It is currently possible to use SpiderMonkey at the level of ff3 for real work. There's a bit of a learning curve, but it's totally usable. In theory, anything you write for SpiderMonkey-trunk will be usable with the new tracing stuff they've built. That's not in CVS, it's in hg (mercurial), and I'm not sure what state it's in right now. I'm guessing it's probably usable, too. Oh, I think the tracing code also requires a C++ compiler, although I could b

  • by cathector ( 972646 ) on Saturday September 20, 2008 @03:20PM (#25086819)
    i have a page which does some numerical simulation in javascript,
    essentially an O(N^2) finding-nearest-neighbors-in-two-dimensions thing,
    and here are some trials w/ 2000 points, on an x86 windows machine:

    Safari 3.1.2          - ~50 seconds, maybe more
    Safari 3.1.2 + Webkit - ~10 seconds
    Firefox 3.0.2         - ~22 seconds
    Chrome 0.2.149.30     - ~19 seconds

I THINK MAN INVENTED THE CAR by instinct. -- Jack Handley, The New Mexican, 1988.

Working...