Slashdot Mirror
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."
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
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.
May the Maths Be with you!
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!
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.
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.
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.