Mozilla really needs to step it up. TraceMonkey is still way behind V8. They need to do something to get competitive with Chrome in terms of performance, or there's no possibility of ever switching back for me. Chrome is always 2-3x faster.
I've been using Chrome the past couple of weeks on my Mac. But the last few days, that stupid font bug has been coming up again and I've been forced to switch back to Firefox...and it sucks.
Out of interest, what does that give you? I haven't had FF crash in months, so it wouldn't make it any more stable for me - is there some other gain from process-per-tab?
I'm not getting very good numbers on my
machine (much higher gc times than the article suggests). Perhaps it's because I'm on a mac, but it's a pretty new MacBook and safari seems to perform much better on a number of them.
safari seems to perform much better on a number of them
The benchmarks on the page are mostly not intended to test relative performance across browsers other than Firefox, and almost certainly do not provide useful comparison data. They were mostly designed to exercise particular performance weaknesses in Firefox, and indicate whether those performance weaknesses are improved by the new code. Micro-benchmarks in the context of very large, complex, systems, are usually pointless...except when going after particular performance issues, as the developers of Firefox are doing.
Came here to make the same comment. The GC benchmark has noticeable pauses on a Core 2 Duo (early 2009) MBP running 10.6. I saw figures of at least 60+ ms when the animation jerked.
I wrote a completely useless 3D effect using DOM manipulation some time ago (http://portfoli.no), and have been using it since to do my own personal benchmark of various browsers. Being horribly unoptimized, and probably riddled with flaws, it seems a fair middle ground for most JavaScripts out there.
FF3.6 is (obviously) by far outperformed by Chrome, but it seems to me that even 3.5x did a better job of running it. In either case, the 3.5->3.6 difference seems marginal for this one.
I've got a pretty weak single core laptop and I have to say those benchmark tests are by far much much much faster in ff3.6, these are my results:
Garbage collection:
19 - 14
651 - 83
dom manipulations:
213 - 136
269 - 34
string:
400 100
120 122
410 16
230 66
Ok, the tests they provide are used to test those things that are supposed to get faster, so it's reasonable to believe it will, but the results are pretty good none the less.
(I ran the tests multiple times in both browsers to get the average)
I have been using chrome.jit for a while with conkeror, which leans on the Javascript engine quite hard. It makes it noticeably faster. Not a little faster, but "holy shit, that was fast" faster. Back when JIT was first shipped in a release build, I enabled it on my eeepc, but not my more-powerful 64-bit desktop (since there was no JIT for x86_64 at that time). The interface was much faster on the eee than on my desktop. (Pages loaded slower, of course, because Javascript was not the bottleneck. But the UI was much faster.)
Anyway, this is great news. Who ever thought back in 1995 that their glorified blink-tag-scripting-language would be compiled to native code? :)
> First, we noticed that a large fraction of the [GC] pause time was spent calling free to reclaim the unused memory.
How about actually implementing a garbage collector? You know, the kind that doesn't have to go around freeing memory?
(I'm being somewhat facetious, as retrofitting a precise compacting GC into a codebase not set up for it isn't trivial, but it is the right direction to move in if you actually want decent GC performance.)
I never noticed the supposed speed improvements of Firefox 3.5. In fact, it was the slowest browsing experience I've had in recent years (and yes, I tried disabling all the add-ons!). I don't have much faith that 3.6 will be noticeably faster.
Firefox, thanks for toppling the IE monopoly, but I'll be using the faster Google Chrome now.
I installed the new Firefox a few days ago, but it feels clunky, bloated, and slower than Chrome. What happened to the old Firefox that was so streamlined and light on its feet? Over time, it seems to have been transformed into the Mozilla of old. They really need to get it in gear.
[+] [-] rufugee|16 years ago|reply
[+] [-] yason|16 years ago|reply
It's funny how such a seemingly meaningless architectural decision can turn into such a disruptive feature.
[+] [-] cookiecaper|16 years ago|reply
[+] [-] alanthonyc|16 years ago|reply
I've been using Chrome the past couple of weeks on my Mac. But the last few days, that stupid font bug has been coming up again and I've been forced to switch back to Firefox...and it sucks.
[+] [-] AndrewDucker|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
[+] [-] tolmasky|16 years ago|reply
[+] [-] SwellJoe|16 years ago|reply
The benchmarks on the page are mostly not intended to test relative performance across browsers other than Firefox, and almost certainly do not provide useful comparison data. They were mostly designed to exercise particular performance weaknesses in Firefox, and indicate whether those performance weaknesses are improved by the new code. Micro-benchmarks in the context of very large, complex, systems, are usually pointless...except when going after particular performance issues, as the developers of Firefox are doing.
[+] [-] maukdaddy|16 years ago|reply
[+] [-] Tichy|16 years ago|reply
[+] [-] einaros|16 years ago|reply
FF3.6 is (obviously) by far outperformed by Chrome, but it seems to me that even 3.5x did a better job of running it. In either case, the 3.5->3.6 difference seems marginal for this one.
[+] [-] FooBarWidget|16 years ago|reply
[+] [-] pohl|16 years ago|reply
[+] [-] arnorhs|16 years ago|reply
Garbage collection:
19 - 14
651 - 83
dom manipulations:
213 - 136
269 - 34
string:
400 100
120 122
410 16
230 66
Ok, the tests they provide are used to test those things that are supposed to get faster, so it's reasonable to believe it will, but the results are pretty good none the less.
(I ran the tests multiple times in both browsers to get the average)
[+] [-] jrockway|16 years ago|reply
Anyway, this is great news. Who ever thought back in 1995 that their glorified blink-tag-scripting-language would be compiled to native code? :)
[+] [-] barrkel|16 years ago|reply
> First, we noticed that a large fraction of the [GC] pause time was spent calling free to reclaim the unused memory.
How about actually implementing a garbage collector? You know, the kind that doesn't have to go around freeing memory?
(I'm being somewhat facetious, as retrofitting a precise compacting GC into a codebase not set up for it isn't trivial, but it is the right direction to move in if you actually want decent GC performance.)
[+] [-] techiferous|16 years ago|reply
Firefox, thanks for toppling the IE monopoly, but I'll be using the faster Google Chrome now.
[+] [-] whyenot|16 years ago|reply
[+] [-] t3rcio|16 years ago|reply