Submitted by “Mozilla has published the first Firefox build that integrates a new JavaScript engine that aims to match the performance in IE9 and reduces the gap to Safari, Opera and Chrome. The JavaScript performance is pretty dramatic and, at least on our test system, Firefox 4 is now faster than IE9 PP4.”
Do these new FF builds support some sort of client-side database capability, like when you want to build an app that could store data locally without needing a web server installed? I recall reading an article that said IE and Chrome could do it, but don’t recall anything mentioned about Firefox.
https://developer.mozilla.org/en/DOM/Storage
No! totally against this – web apps should be entirely independent of the client … don’t reinvent local web apps which are ..er .. slower than native local apps …
There are actually 4 things to help support mobile/disconnected usage of webapps:
– a session storage
– a domain-based storage (application browser/local storage)
– a websql database support, also per domain
– a manifest file is added to the page, to show which files belong to the application and can all be downloaded and kept in the cache as a whole
All these combined will make it possible to create applications which work for mobile and in a disconnected world.
Not sure how you expect that to work… There is no such thing as a web app that is “independent of the client”. A web app is nothing more than a collection of text and data files, you need something to actually “run” it, i.e. the client. Adding persistent storage to the runtime simply makes it easier/faster to accomplish certain things – how this can be interpreted as anything but a good thing I can’t fathom…
He’s referring to the client OS, not the browser.
How? There is nothing about the implementation of DOM storage in FF that is OS specific. Unless I am missing something (I don’t think I am) It is identical across all platforms…
But still slower than anything WebKit-based…
It’s closing in on Safari, it should outspeed it before 4.0 release (by looking at arewefastyet graph)
Maybe for JavaScript but JS is only one variable in the overall performance calculation.
WebKit’s HTML and CSS rendering is also much faster than Firefox, especially on non-Windows platforms.
Firefox 4.0 includes hardware acceleration for rendering:
http://www.downloadsquad.com/2010/06/24/4-way-html5-speed-test-fire…
Firefox 4 is the fastest browser in the four-way (IE9, Firefox 3.7, Chrome and Opera) rendering test linked above.
The webkit browser, which is Google Chrome, is actually the slowest.
Only on Windows Vista+, only on recent hardware. Pass.
Sigh!
Where do you guys get this from? Do you make it up in your sleep or something?
http://hacks.mozilla.org/2010/09/hardware-acceleration/
Under the heading “Hardware Acceleration by operating system”, this article from Mozilla says that Firefox 4.0 on Linux will use Xrender for hardware acceleration of content and OpenGL for hardware acceleration of compositing.
On Windows XP Firefox 4.0 will have hardware acceleration for compositing only.
The latest Firefox 4.0beta release announcement.
The latest Firefox 4.0beta release announcement is about the latest Firefox 4.0beta. It is not about what will be enabled in Firefox 4.0.
Mozilla hacks website is about what will be enabled in Firefox 4.0, and what might not be.
http://hacks.mozilla.org/2010/09/hardware-acceleration/
PS: the latest firefox beta release announcement made no mention of what acceleration methods were being used on Linux.
Edited 2010-09-11 18:42 UTC
“will” … “might” …
Stop playing an oracle and concentrate on the present and in the present Firefox is slow and all major WebKit variants are way faster.
They are not way faster than Firefox 4.0b6.
I know this because I am running Google Chrome and Firefox 4.0b6 on the same system, and I can compare them side by side.
Firefox 4.0b6 is not vapour-ware, it is a pre-release version that you can run and check out for yourself.
PS: I would not sound at all like an oracle if it weren’t for all of the utterly wrong things which you keep trying to claim about firefox. Those errors on your part are the only thing which is making an oracle out of my posts.
Edited 2010-09-11 18:39 UTC
There is no Beta 6. Beta 5 is the latest.
http://ourlan.homelinux.net/qdig/KDE4_desktop/mozilla-firefox-versi…
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk…
PS: 4.0b5 doesn’t have Jaegermonkey, BTW. Jaegermonkey didn’t exist back then, because Jaegermonkey is only two weeks old.
Edited 2010-09-11 18:58 UTC
The fact alone that you can’t differentiate between Beta 6 and a pre-beta nightly (“pre” is part of the version number for a reason) speaks more than 1000 words about your incompetence in IT.
No need to discuss any further. I’m attending social life now than continuing to waste my time with some random pseudo expert.
The translator chip in my brain says
“I’m desperate to get the last word, but I realize how stupid what I said on this thread was and how short of arguments I am now, so I’ll just try to hit my opponent in the balls with something which hurts because I feel hurt myself, and then quickly flee to hide how shameful I feel”.
What makes it most comic is that lemur2 probably has just as much of a social life as you and me, making you sound just even more silly.
Let’s recall what you said in this thread.
* Firefox is slower than anything Webkit-based (right, but not for a long time. Mozilla are finally catching up in this competitive area, and that’s better for everyone in the end)
* You assume that webkit stands still (it does, looking at the graphs. OTOH, Mozilla may have used current releases of Safari and Chrome instead of nightlies, which would be a bit unfair, but as far as I know and as the Chrome 6 release shows it best, webkit’s current priority is not performance)
* Webkit’s rendering of most websites is perfect (Wrong. Most websites are made for IE6 or IE7, and webkit has the worst IE compatibility around. It’s then followed by Opera’s engine, which is already much better, then Gecko which is even better because of the Mozilla legacy of competition with IE as the dominant browser, and obviously Trident (IE) itself)
* Webkit browsers are much faster at rendering webpages than Firefox (Wrong. The perceived difference in performance is small, as pointed out by ndrw. Javascript speed is just a game for geeky developers where browsers are close to each other in ordinary conditions. What’s horribly slow in Firefox is its UI, and I hope they’ve finally done something about it in firefox 4 prereleases)
* Firefox 4’s hardware acceleration will only works on Windows ( http://www.youtube.com/watch?v=tRVUOGUmxJI )
* Firefox+Qt is in active development because of Meego (Maybe right, maybe wrong. As far as I too know, Nokia were rather planning to use WebKit as their main browser)
* x86 is legacy, x64 is current gen (Absolutely and totally wrong. The good wording is that x86 is still current gen and x64 is still next gen, as of today, because 64-bit mode requires OS support to be activated and otherwise hardware runs in x86 emulation mode, just like in Mozilla’s tests. A large majority of today’s computers run Windows XP x86, a smaller part runs Windows Vista x86, and only then you’ll find Windows 7 x64 because Microsoft finally shakes its ass. Apple only got interest in 64-bit technology rather recently, and Linux/BSDs are a small minority. So x64 is an interesting platform to develop on, but by no mean, if you want to target users as a whole and not solely computer geeks, it should be top priority. It’s still only a plus, really. By the way, noticed the performance difference in webkit between x86 and x64 in those tests ? Absolutely nothing. Curious, the extra registers should have had some effect…)
* Firefox on ARM is still not mature (Finally, you’re right. Strangely, no one followed this up)
* JaegerMonkey is older than two weeks old, why should it improve ? (Terminologically wrong. It’s a very young merge of two older engines. The merging still has to be worked on, there can be a performance gain there)
* Then, short of argument, you repeated yourself about speed, hoping that it makes it more true (No.)
* Then you explained that there was a world of difference between a beta and a pre-release build, knowing that said build will become a beta in a few days or weeks and that developers only have a limited working ability (Not really… Betas are just fully packaged trunk builds for those who are afraid of unpacking a zip file including a trunk build)
Well… Still, congratulations to lemur2 and other posters on this thread for keeping calm and patiently answering his points.
Edited 2010-09-12 05:03 UTC
TM+JM is actually faster than Nitro and V8 on some tests: http://arewefastyet.com/individual.php?machine=5
http://arewefastyet.com/individual.php?machine=4
They don’t. Mouse over the individual nodes on arewefastyet.com and check the revision numbers for Nitro and V8. They are using the latest builds.
This is wrong. Mozilla is working on OpenGL/OpenGL ES backends for non-Windows systems. It’s just unclear to me whether they’ll make it for 4.0 or will be postponed to a later version.
There are still some major outstanding performance bugs. Mozilla’s Bugzilla is the right place to track such development if one is interested in that. Some of this will land for 4.0, other will have to be postponed to release the browser in time.
You’re delusional. The improvements to JavascriptCore aren’t static.
Fettarme H-Milch:
Elv13:
The arewefatsyet graph mentioned above is here:
http://arewefastyet.com/
If the trend holds, Firefox 4.0 release will probably be faster than Chrome and Safari. Well it may be a close-run thing against Chrome, but almost certainly Firefox 4.0 will outpace Safari.
BTW, it isn’t webkit per se that gives Chrome and Safari their current slight speed advantage, but rather it is their as-yet more established javascript engines named google V8 and apple nitro respectively.
It is google V8 and apple nitro against which JaegerMonkey competes, not webkit.
Edited 2010-09-11 07:46 UTC
Mozilla says, because they are combining 2 ways of optimizing javascript they will/hope to be faster then anything else.
They will combine the way Firefox has done it since 3.5 and the way webkit-based browsers do it which their 2 javascript implementations (actually 3, but only 2 are still used in current browsers).
Exactly so.
The 2 ways of optimising javascript used are: tracing (used to be called tracemonkey) and JIT compiling.
Jaegermonkey is the engine that results from these two combined. The first time these were combined was about two weeks ago.
Results for the “combined” engine are plotted in purple on this page:
http://arewefastyet.com/
The first purple plot points appeared about two weeks ago, August 31 to be exact. AFAIK this represents the very first build of Jaegermonkey.
Firefox 4 beta 6, which was recently released, and which is the subject of this very thread, is the first beta which includes the Jaegermonkey engine.
You probably mean the current nightly build. Firefox 4.0b6 is scheduled for the second half of September:
https://wiki.mozilla.org/Releases/
Edited 2010-09-12 06:51 UTC
That’s a totally flawed logic. That logic assumes that only Firefox improves while WebKit (Nitro and V8) stands still.
Nitro and V8 are included in the trend graphs.
http://arewefastyet.com/
They are the plots coloured in red and green respectively. Nitro has been steady, but V8 has seen some small improvement, in going from rev 5288 to rev 5322 on August 23rd, within the period covered by the trend plots.
The point stands.
Edited 2010-09-11 15:25 UTC
Funny how you distort reality to fit your argument.
The graph you point to over and over again only shows the numbers for legacy 32bit x86 code.
Let’s look at the numbers for current-gen hardware (x64):
http://arewefastyet.com/?machine=4
Surprise! Nitro is the fastest in SunSpider, V8 close behind, the new TraceMonkey+JägerMonkey engine having pretty much no effect. In V8Bench JM+TM at least gives a performance boost but compared to V8 (the winner there) Firefox is still almost 2 times slower.
On ARM the new engine seems to be not even availabe and Firefox is up to three times slower than V8:
http://arewefastyet.com/?machine=3
x86 code is not legacy code.
32bit x86 is legacy code.
32bit x86 is still the native code for the majority of web-connected machines. Therefore it behoves developers to write for that first, although not all developers do that.
Nevertheless it is not unusual for developers to get it developed and released for x86 first, and then worry about x86_64 only later.
Case in point: The Adobe Flash plugin for web browsers is still not available as x86_64 code.
Doesn’t make it less legacy.
Being legacy doesn’t mean that it should be the first code worked on.
Mozilla keep more users happy by working on x86 first.
In my opinion, it makes it not legacy at all.
http://lmgtfy.com/?q=define%3A+legacy+code
http://arewefastyet.com/faq.html
Bugs get fixed, you know. You have to expect at least a few unfixed bugs in code that is only two weeks old.
Wait until it is released for real in Firefox 4.0, some time in the next couple of months. Bugs should be fixed by then.
Two weeks old? You like to lie a lot, don’t you?
JägerMonkey is older than two weeks, it was just not enabled by default for quite some time.
Jaegermonkey is the merging of two previously separate javascript engines, which were a JIT engine which is new for Mozilla, and Mozilla’s Tracemonkey.
http://arewefastyet.com/
One the graphs, Tracemonkey plot is in gold, which is the ongoing performance improvements in an older engine. Black is the newer JIT compiler engine.
Jaegermonkey is the merging of these two … it is plotted on the graphs in purple. The first plot point is the performance of the very first build ever of Jaegermonkey … it is just two weeks old.
Tracemonkey (gold), the older engine, has been discontinued.
You will note that the JIT engine (black) alone is currently slightly better than Jaegermonkey on the sunspider test. This is due to the nature of the sunspider benchmark itself.
Mozilla address this point in their FAQ at question 7:
http://arewefastyet.com/faq.html
What they mean by the “heuristics” comment is that they will work out a way to make sure that Jaegermonkey uses the JIT engine method alone for sunspider-like javascripts.
PS: Please do not accuse people of lying when they are not. It makes YOU look extremely desperate to try to come up with something (anything) negative about this development code by Mozilla, for no good apparent reason.
Edited 2010-09-11 18:21 UTC
JägerMonkey is still older than two weeks, it was simply not enabled by default in Firefox nightlies but could be enabled manually.
And stop linking to that Mozilla-run website. It’s biased.
Jaegermonkey is NOT older than two weeks. The very first build of Jaegermonkey was August 31, 2010. Before then Mozilla had two separate javascript engines in development, neither of which were Jaegermonkey. One was Tracemonkey, and the other was Mozilla’s new JIT engine.
A Mozilla-run website has an infinitely better grasp of what Mozilla are doing than you do.
Edited 2010-09-11 18:26 UTC
You’ve got your terminology confused. The “new JIT eingine” *is* JaegerMonkey. And just btw, TraceMonkey uses JIT too. It’s just that TM is tracing JIT, while JM is method JIT.
JaegerMonkey has been in development for at least three months, possibly more. It’s just that it was developed in a branch. Then, on August 31st, it has been merged from it’s own branch into the TraceMonkey branch. And yesterday, the now combined JM+TM have been merged into mozilla-central, which is the “trunk”.
Oh, and let’s throw another word into the mix: SpiderMonkey. What is SM? Well, it’s Mozilla’s JS engine as a whole. In the beginning, there was SM, an interpreter JS engine. Then, TM was added to it. And now JM too. So SpiderMonkey now consists of an interpreter, a tracing JIT engine and a method JIT engine.
Sorry about getting the terminology mixed. As I understood it, the now combined JM+TM is JaegerMonkey. Before now there has been no JM+TM, there has only been tracing JIT or method JIT, and no engine which combined them.
The tracing JIT and method JIT components have indeed each been in separate development for quite some time. It is the combination, the merged JM+TM (AFAIK this is called Jaegermonkey) which is only about two weeks old.
No that’s wrong and the other poster is correct.
Jaegermonkey = method JIT compiler
Tracemonkey = tracing JIT compiler
Spidermonkey = generic name for the full javascript compiler, which now contains bother Jaeger and Trace monkeys.
OK, then I misunderstood. From the horses mouth:
https://wiki.mozilla.org/JaegerMonkey
I thought the names were the other way around, and that Jaegermonkey would replace SpiderMonkey.
My bad.
The corrected statement would thus be: “JaegerMonkey integration into SpiderMonkey is only about two weeks old”.
Edited 2010-09-13 04:57 UTC
No, the merged part is not JaegerMonkey. Only JaegerMonkey is JaegerMonkey (duh
).
The whole thing combined is, as it always was, SpiderMonkey.
Note the scales on AreWeFastYet.com. The Firefox method JIT started out roughly 5 times slower on v8bench on x64 and almost twice as slow on sunspider, so the auto-sized graphs are more vertically compressed.
If the initial Firefox results were discarded or allowed to be off the top of the graph, more recent tests would look more or less the same as the 32-bit x86 machine’s graph.
Perhaps more interestingly, nobody seems to mention that Firefox is the only browser which is working to share the same JIT implementation between all supported platforms.
Last I heard, things like SquirrelFish Extreme and V8 have to do a lot of re-implementing for each new platform. (I still remember waiting over a year to try Chrome on 64-bit Linux because of that fact and my stubborn refusal to grow attached to any 32-bit-only app)
Edited 2010-09-13 03:58 UTC
According to arewefastyet.com (which is a mozilla website though), it is the case. More exactly, V8 has improved a little bit, but not nearly at the speed of FF4’s pre-release code.
Edited 2010-09-11 16:44 UTC
On the other hand (I am king of arguing against myself…) XUL-UI is based on web technologies like XML, HTML and CSS. Safari and Chrome use native rendering mothod directly, while Firefox use a proxy above GTK, Win32, Cocoa or Qt (dying). This kind of rendering add bad performance penalties. It is affected by the over overhead of the accumulation of layer, the fake theme native theme engine, the CSS layer, badly written extensions/theme -and- the JavaScript engine threading problem/lack of process isolation.
That alone make Firefox the slowest of them all. Only 1 process to render (only) the GUI frame will be needed to make it responsive with more than 30 tabs. Chome and IE are not even affected by the number of tabs, Firefox is (for now and for the year to come). Plugin isolation is cool to prevent crashed, but it does not prevent slowdown with multiple heavy web pages open at once.
Actually Firefox+Qt is in active development because of Firefox Mobile on Maemo/MeeGo.
Old news, last time I saw MeeGo, it was using WebKit.
MeeGo Handset uses the Qt port of Firefox Mobile by default.
It uses Fennec and thus – Gecko.
Who cares if its faster then half the pages I visit in Safari on my Mac are rendered incorrectly?
I’ll stick to FF.
That’s a balant lie. I’m on Linux using Qt’s WebKit port — a port that’s far less advanced than Safari or Chrome — and every web site renders perfectly. QtWebKit’s only flaw is only partial support for plugins (only Flash officially supported) but that flaw does not appear in Chrome or Safari.
It’s not a lie (how can you accuse someone you don’t know of lying BTW?). Firefox was designed to compete against IE. This means that it should handle all the broken and non standard HTML people throw at it. Considering this, when I’m browsing with Opera and Chrome I see from time to time some non-standards compliant page that doesn’t look properly in anything but IE and Firefox.
For example, I’ve seen a site that uses the following code to add some arbitrary space between paragraphs or elements:
In Opera and Chrome this looks like ass because font-size on < br > is not interpreted.
Sure, this is not the proper way to add spacing, but nonetheless it exists in the wild. And this is just one example out of many possible.
Most people first want a browser that works, not one that is 5% faster on a Pentium 4 from 7 years ago.
You should get Thunderbird and start mailing some webpage authors! Sounds like some shitty written html pages if webkit can’t display them correctly.
I didn’t have any issues with speed of Firefox since 3.6. UI was a laggy but rendering speed was fine. Perhaps in benchmarks Chrome was faster but on real websites the difference was hardly noticeable.
Now I’m using 4.0b5 – UI got much faster (since it’s written in JavaScript it means their fixes work) but as far as web is concerned – I couldn’t care less. Is 4.0b5 faster? Good, just hope they don’t sacrifice stability for 20% speedup.
With performance of all major browsers closing in, what matters is functionality, portability, reliability, privacy (I’m dreaming about a nice cookie manager/swapper) etc. That’s good – finally we have a choice.
4.0b5 includes only the improvements in tracemonkey.
http://arewefastyet.com/
It is effectively the end of the gold plot line in the graph linked above.
4.0b6 is the first build to include Jaegermonkey, which is the end of the purple plot line. Jaegermonkey represents a significant improvement, even though it is only two weeks old.
I think FF4 promises to include this…
See slide 14 in this slideshow of Mozilla’s plans for FF4 : http://www.slideshare.net/beltzner/firefox-roadmap-2010-0510?from=s…
Like most of Mozilla’s plans for firefox 4, it looks great on screenshots. Now, let’s see how the final implementation will be…
Edited 2010-09-11 16:57 UTC
Just upgraded from B5 64bit -> B6pre 64bit… It is a -lot- slower than b5, switching back, submitting bug.
Don’t have to say more, the title says it all.
Do you know if the new firefox is buildable with mingw/mingw-w64 without dependencies on PSDK? Only mingw distribution + open source dependencies? Is JaegerMonkey slightly faster then?
Edited 2010-09-13 18:33 UTC