Firefox 4's JavaScript Now Faster Than Chrome's

An anonymous reader writes "Firefox 4's JavaScript engine is now faster than V8 (used in Chrome) and Nitro (used in Safari) in the SunSpider benchmark on x86. On Mozilla's test system Nitro completes the benchmark in 369.7 milliseconds, V8 in 356.5 milliseconds, and Firefox 4's TraceMonkey and JaegerMonkey combination in 350.3 milliseconds. Conceivably Tech has a brief rundown of some benchmark figures from their test system obtained with the latest JS preview build of Firefox 4: 'Our AMD Phenom X6-based Dell XPS 7100 PC completed the Sunspider test with the latest Firefox JS (4.0 b8-pre) build in 478.6 ms this morning, while Chrome 8.0.560.0 clocked in at 589.8 ms.' On x86-64 Nitro still has the lead over V8 and TraceMonkey+JaegerMonkey in the SunSpider benchmark."

Comments

FF4

[Anonymous Coward]

FF4 crashes when I try to open Gmail since the change. This makes it slower for opening my mail.

1. connect to gmail with FF4
2. FF4 crashes.
3. Open chrome and go to gmail
4. ??? (train monkeys to joust)
5. Profit

6 milliseconds! Wheee!!!

[Joce640k]

I'll be able to do one more mouse click every three weeks or so.

Re:6 milliseconds! Wheee!!!

[Anonymous Coward]

I'm not looking forward to 'the next level' of the web. It will only have more dancing and blinking crap on the page.

Want to make you site fast? You don't need Ajax, Flash, or any other "Hype du Jour". Toss it all out, stick with plain old HTML and make it look decent with simple CSS. Wham, your site is now an order of magnitude faster. You don't need those five load balancers and those twenty application servers just to serve up a page that could easily run on one server when you actually had a clue.

The Web is rapidly going the way of television: once it was about content, then ads came 'to pay for the content' and now it is all ads with the absolute minimum of content. Spreading a two paragraph article over eight pages just to have more ad impressions. Six pictures that just have to be in a slide show. Ads. Profit. Bottomline.

Get me a bucket, I'm going to hurl...
 

Re:6 milliseconds! Wheee!!!

[Jahava]

I'm not looking forward to 'the next level' of the web. It will only have more dancing and blinking crap on the page.

Want to make you site fast? You don't need Ajax, Flash, or any other "Hype du Jour". Toss it all out, stick with plain old HTML and make it look decent with simple CSS. Wham, your site is now an order of magnitude faster. You don't need those five load balancers and those twenty application servers just to serve up a page that could easily run on one server when you actually had a clue.

Want to view content? I agree with your theme in that case, and there are plenty of sites out there that are designed around just that: simple presentation-focused static content display.

However, most of the impetus for "Web 2.0" has not been around content viewing, but rather about utilizing the web browser as an effective, cross-platform thin client for applications. Now, granted, some sites are (ab)using AJAX and whatnot for purposes ranging from nefarious to just annoying, and there is some spillover from the dynamic application-based web pages into the static information-based ones, but it's generally kept in balance by the ease with which people can transition to a competing website if yours is too annoying.

Recent advancements in Javascript execution speed are oriented towards polishing the thin client experience and capabilities. If fast Javascript execution becomes ubiquitous, sites can design much more successful thin clients because they can take that execution speed for granted. It's not all just flashing lights and annoying ads: take a look at the stunning Deluge BitTorrent Client's Web UI to see how nicely "Web 2.0" can be used.

Re:6 milliseconds! Wheee!!!

[Wraithlyn]

1) Nobody uses load balancers and multiple app servers because they're serving "dancing and blinking crap" (Flash and JS heavy) sites. Those things slow down people's browsers, not the servers. Heavy server resources are needed when you need lots of server side processing, which generally comes from delivering customized pages to every user (ie you can't just cache everything). Furthermore, using AJAX helps REDUCE server load, by only requesting snippets of content, instead of complete page requests; you think GMail would be faster and less server-intensive if every click required a full page response? How about Google Maps?

2) You seem to be under the impression that developers actually design sites. Maybe in some tiny one-man-show setup, but in the real world a UX/IA specialist designs the user experience, a designer does the visuals, the client signs off on it, and then the developer makes it all happen using whatever tools and techniques are necessary. They don't have the option to "toss it all out" and make it as simple as they like, much as they'd like to. Heck, I have to fight to make sure there's accessible fallback versions of the fancy JS-enhanced UIs everyone designs these days. "Throw it all out"? You live in a dream world buddy, or you do work of extremely limited scope.

In short, your post is just "get off my lawn!". More and more clients demand rich user experiences, and this will continue to grow. Welcome to 2010.

What Mozilla giveth, Slashcode taketh away.

[Anonymous Coward]

Why do I have a feeling that Slashcode's terrible AJAX interface is going to get even worse in the near future?

This is quite possibly the lamest e-peen measuring contest ever.

Re:What Mozilla giveth, Slashcode taketh away.

[DarkOx]

Yea, what is even more irritating is they keep subjecting us to it. Even thought the boxes stay checked I have had to go to my user preferences and turn on and then back off the new comment system several times in the last two weeks. I hate it, based on the comments I read here on Slashdot just about everyone else hates it two. Some of them are just Luddites that want the Slashdot of 1997 period but the rest of us just hate because its an awful way to browse and read comments, awful (GET IT TACO AWFUL) so many other sites have gotten it write, if you feel he need to update the look and feel of Slashdot go look at what others are doing!

Re:What Mozilla giveth, Slashcode taketh away.

[Sancho]

I actually like d2. I hate loading new pages for comments below my threshold. I just wish d2 worked better on iOS.

Re:What Mozilla giveth, Slashcode taketh away.

[moonbender]

I think Slashdot's AJAX is pretty poor, certainly not in line with what some of the better AJAXy sites do. That said, and even though I also keep having to look for stuff, I really love being able to things like in-line previewing and replying. I used to open the reply link in another tab, but that's a bad workaround. And changing the treshold without reloading the whole page is also nice, as is opening up "titles only" posts.

Benchmarks

[markdavis]

I am sure this will set off a whole series of arguments over benchmarks, tuning, fairness, etc. But from this article I will just take this: I don't care which one is fastest to the few dozen milliseconds, they are probably all in the same "class" now. Everybody wins. (I can sorta understand not including IE, but wonder why they didn't include Opera?)

Now that Javascript is so much faster, perhaps the browsers can focus on giving some type of automated/intelligent control over when it is used and how so older machines won't come to a CRAWL because of all the cutesy animation and junk spread over most big sites now. (And no, NoScript doesn't cut it- too complicated for most users, not automatic, too easy to break Javascript that is actually needed, etc). Suppress time-delayed actions, disable tight loops, throw artificial delays in loops under user control, visually tag elements to manually "play" on-demand only or stop after X seconds. I know, keep dreaming.

Thanks for the hard work

[DontLickJesus]

Seeing that Firefox on a few weeks ago was starting to lag pretty severely behind Chrome, I applaud and thank the Firefox team for their hard work. This is also a boon for their technique, the so-called "shotgunning" method of pushing through compilation the old way if it will complete faster than the optimizations. I had become afraid I might have to move to Chrome, looks like that won't be necessary.

As a developer I completely understand the dislike of the "everything in a browser" attitude, but we need to look beyond that. The next version of ECMAScript will give us the security we've been wanting, and this round of browsers will give us the speed we need. Enabling universal, secure process level interaction between machines is the goal. You can think of it as widgets, .Net, or whichever other poison you want, but Javascript is free of ownership and frankly a damn good language when written properly.

Now give me an 100% on the Acid3 test please, that way I'll have multiple tools to leverage against my boss next time he asks me to make a web app IE6 compatible.

Re:Thanks for the hard work

[BZ]

There are several things wrong here:

1) Spidermonkey still compiles the AST to bytecode.
2) An assembler does just that: assembles. This means a 1-1 mapping of some other sort of
        representation of the exact machine instructions you want into actual bits in memory.
        There are no smarts here and no optimization going on; the only question is how fast
        you generate those bits in memory; an ideal assembler does this as fast as possible
        and without using too much memory. Now you have to generate assembly (or whatever
        representation the assembler takes as input) for it to assemble. That's the job of
        the compiler. JaegerMonkey takes the bytecode generated in step 1 and compiles it,
        passing the output to the assembler borrowed from Nitro. This compilation step is
        where (some of) the optimization takes place, and this is not code shared with Nitro.
3) Tracemonkey is most certainly useful for Sunspider; just not as useful as for other
        things. See, for example, http://arewefastyet.com/?machine=6 where the purple line is
        below the black one solely because of Tracemonkey. Alernately, see
        https://bug580468.bugzilla.mozilla.org/attachment.cgi?id=482609 where you can see the
        scores on each sunspider subtest as of a week or so ago; the -m column is JaegerMonkey
        without Tracemonkey, -j is Tracemonkey without Jaegermonkey, and -mjp is what's
        actually being used now (a combination of the two, with some smarts about deciding
        when to use which one).
4) The goal of Kraken is in fact to include anticipated use cases. If you know
        anticipated use cases it doesn't include, I'm sure Rob Sayre would love to know what
        they are.

and yet Firefox still can't use 1 core... :(

[electrosoccertux]

Tell me, mr anderson, what good is javascript performance if you are unable to use multiple cores?

I wish someone would get on this and make firefox work with multiple cores better. As it is I use the "|" character in my home page settings to open about 20 tabs-- forums, review sites, slashdot, economics blogs, etc....and firefox slows to a grinding halt for about the 15 seconds (just timed it) it takes to render all those pages.
Chrome does it in about 4 seconds and pegs all 4 of my cores to 100%.

Please Mozilla, I know this would require a serious redesign, but it's seriously needed. Hitching while scrolling up/down because a tab is loading in the background (I make use of middle click to open tabs in the background extensively) is very annoying.

Re:and yet Firefox still can't use 1 core... :(

[hedwards]

They're working on it. It's just a matter of wanting to do it correctly rather than just doing it to say they've done it. Sort of like how they've resisted cheating on the Acid tests like some of the other browsers have been.

Just about any moron can make a new browser window per tab and not have them talking to each other. But it takes a fair amount of work to get them connected enough for performance reasons without causing one tab to crash others.

Interesting?

[mseeger]

I really don't see the point in a posting like this. Its all

        My _______ (1) is _______ (2) than yours

with typical choices for (1):

- car
- wife / husband / significant other
- d*ck
- browser
- javascript
- OS

and choices for (2) like:

- faster
- harder
- more expensive
- longer
- more open
- prettier

Now that we have covered all these discussions, can we move on please?

CU, Martin

Re:FF4 has some pretty serious memory leaks still,

[ObsessiveMathsFreak]

It's not a memory leak problem. This is pretty obvious when, after weeks of continuous use, Firefox's memory usage remains more or less constant.

However, Firefox does have a memory fragmentation problem. After continuous use, the program will become noticeably slower on certain tasks which it previously had no issues with. This is particularly the case if you're visiting more intensive webpages. Often you're better just restarting it after the first 100 or so tabs.

Re:FF4 has some pretty serious memory leaks still,

[Anonymous Coward]

As I've said, I've tried this. Firefox's memory use tops 200 MB after two weeks. Other browsers go over 200 MB in a few days. I'm not attacking you, just stating for the record that I cannot see a problem. Perhaps on your computer that problem exists. Do not assume that every other Firefox user in the world sees the same problem. I do not. If you don't believe me, look at any number of memory tests that show Firefox using less memory than other browsers: 1 2 3 4, and many more!

Most of Firefox is written in JavaScript.

[Anonymous Coward]

I know, I know, it's damn near impossible to believe, but the Firefox developers voluntarily chose to write a huge portion of Firefox in JavaScript and XML (XUL). The rendering engine and network stack are written in C++, but just about everything else is implemented using JavaScript and XUL, including all of the UI.

This is why JavaScript performance is so important to Firefox. While other browsers didn't make the same mistake, and wrote the bulk of the browsers in a real language like C++, the Firefox developers chose what is probably the stupidest architecture possible. A slow JavaScript implementation means their entire browser is slow, rather than just any web pages that might use JavaScript in some way.

Re:FF4 has some pretty serious memory leaks still,

[someone1234]

I think they forget that page caching is not a leak.

Verified on my sw-only 3D benchmark as well

[ttsiod]

I, too, saw the speed of Firefox 4 in a pretty simple, math-only benchmark that rotated a 3D object. Run it for yourself and/or see the gathered statistics (bottom of the page). Here is the Reddit discussion where many people run it and confirmed Firefox 4 supremacy.

Please stop moaning!

[mykdavies]

Jesus guys, can't you just congratulate the Firefox devs on the great job they're doing? Just look at the rate of improvement over the past few months and give the JaegerMonkey/TraceMonkey guys kudos for a really impressive job of software engineering. Have a look at David Mandelin's recent post to get an idea of how much work and planning has gone into this project.