Linked by Thom Holwerda on Fri 10th Sep 2010 15:06 UTC, submitted by lemur2
Mozilla & Gecko clones "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."
Order by: Score:
Client-side
by WorknMan on Fri 10th Sep 2010 21:10 UTC
WorknMan
Member since:
2005-11-13

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.

Reply Score: 2

RE: Client-side
by Kroc on Fri 10th Sep 2010 21:26 UTC in reply to "Client-side"
Kroc Member since:
2005-11-10
RE[2]: Client-side
by project_2501 on Fri 10th Sep 2010 21:54 UTC in reply to "RE: Client-side"
project_2501 Member since:
2006-03-20

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

Reply Score: 1

RE[3]: Client-side
by Lennie on Fri 10th Sep 2010 23:32 UTC in reply to "RE[2]: Client-side"
Lennie Member since:
2007-09-22

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.

Reply Score: 4

RE[3]: Client-side
by galvanash on Sun 12th Sep 2010 17:15 UTC in reply to "RE[2]: Client-side"
galvanash Member since:
2006-01-25

No! totally against this - web apps should be entirely independent of the client


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

Reply Score: 2

RE[4]: Client-side
by tyrione on Sun 12th Sep 2010 20:49 UTC in reply to "RE[3]: Client-side"
tyrione Member since:
2005-11-21

"No! totally against this - web apps should be entirely independent of the client


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.

Reply Score: 2

RE[5]: Client-side
by galvanash on Mon 13th Sep 2010 00:59 UTC in reply to "RE[4]: Client-side"
galvanash Member since:
2006-01-25

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

Reply Score: 2

Fettarme H-Milch
Member since:
2010-02-16

But still slower than anything WebKit-based...

Reply Score: 1

Elv13 Member since:
2006-06-12

It's closing in on Safari, it should outspeed it before 4.0 release (by looking at arewefastyet graph)

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

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.

Reply Score: 2

lemur2 Member since:
2007-02-17

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.

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

Firefox 4.0 includes hardware acceleration for rendering

Only on Windows Vista+, only on recent hardware. Pass.

Reply Score: 2

lemur2 Member since:
2007-02-17

"Firefox 4.0 includes hardware acceleration for rendering

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.

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

Where do you guys get this from? Do you make it up in your sleep or something?

The latest Firefox 4.0beta release announcement.

Reply Score: 2

lemur2 Member since:
2007-02-17

"Where do you guys get this from? Do you make it up in your sleep or something?

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

Reply Score: 2

tyrione Member since:
2005-11-21

It's closing in on Safari, it should outspeed it before 4.0 release (by looking at arewefastyet graph)


You're delusional. The improvements to JavascriptCore aren't static.

Reply Score: 2

lemur2 Member since:
2007-02-17

Fettarme H-Milch:

But still slower than anything WebKit-based...


Elv13:
It's closing in on Safari, it should outspeed it before 4.0 release (by looking at arewefastyet graph)


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

Reply Score: 3

Lennie Member since:
2007-09-22

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

Reply Score: 2

lemur2 Member since:
2007-02-17

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.

Reply Score: 3

shmerl Member since:
2010-06-08

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

Reply Score: 1

Fettarme H-Milch Member since:
2010-02-16

If the trend holds

That's a totally flawed logic. That logic assumes that only Firefox improves while WebKit (Nitro and V8) stands still.

Reply Score: 2

lemur2 Member since:
2007-02-17

"If the trend holds

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

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

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

Reply Score: 2

rebus Member since:
2009-10-25

x86 code is not legacy code.

Reply Score: 1

Fettarme H-Milch Member since:
2010-02-16

x86 code is not legacy code.

32bit x86 is legacy code.

Reply Score: 2

lemur2 Member since:
2007-02-17

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

Reply Score: 2

lemur2 Member since:
2007-02-17

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.


http://arewefastyet.com/faq.html
Why is the JM+TM line slower than JM on SunSpider?

We're working on this - see bug 580468. The deal is that SunSpider is very short running, as it was developed before any JavaScript JITs existed. Trace compilation usually works best on longer running benchmarks. We'll have heuristics to make sure the right JIT comes into play at the right time.

...

Why is x64 JM slower than x86?

x64 performance work is still ongoing. We're still working on value performance and register allocation - see for example bug 587444.


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.

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

You have to expect at least a few unfixed bugs in code that is only two weeks old.

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.

Reply Score: 2

lemur2 Member since:
2007-02-17

"You have to expect at least a few unfixed bugs in code that is only two weeks old.

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


Why is the JM+TM line slower than JM on SunSpider?

We're working on this - see bug 580468. The deal is that SunSpider is very short running, as it was developed before any JavaScript JITs existed. Trace compilation usually works best on longer running benchmarks. We'll have heuristics to make sure the right JIT comes into play at the right time.


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

Reply Score: 3

ssokolow Member since:
2010-01-21

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

Reply Score: 1

Neolander Member since:
2010-03-08

That's a totally flawed logic. That logic assumes that only Firefox improves while WebKit (Nitro and V8) stands still.

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

Reply Score: 2

Elv13 Member since:
2006-06-12

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.

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

Qt (dying)

Actually Firefox+Qt is in active development because of Firefox Mobile on Maemo/MeeGo.

Reply Score: 2

Elv13 Member since:
2006-06-12

Old news, last time I saw MeeGo, it was using WebKit.

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

Old news, last time I saw MeeGo, it was using WebKit.

MeeGo Handset uses the Qt port of Firefox Mobile by default.

Reply Score: 2

shmerl Member since:
2010-06-08

It uses Fennec and thus - Gecko.

Reply Score: 1

Kivada Member since:
2010-07-07

Who cares if its faster then half the pages I visit in Safari on my Mac are rendered incorrectly?

I'll stick to FF.

Reply Score: 2

Fettarme H-Milch Member since:
2010-02-16

half the pages I visit in Safari on my Mac are rendered incorrectly


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.

Reply Score: 3

pandronic Member since:
2006-05-18

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:

< br style="font-size:7px" >


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.

Reply Score: 3

Brunis Member since:
2005-11-01

Who cares if its faster then half the pages I visit in Safari on my Mac are rendered incorrectly?

I'll stick to FF.


You should get Thunderbird and start mailing some webpage authors! Sounds like some shitty written html pages if webkit can't display them correctly.

Reply Score: 2

Speed is fine
by ndrw on Sat 11th Sep 2010 14:45 UTC
ndrw
Member since:
2009-06-30

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.

Reply Score: 2

RE: Speed is fine
by lemur2 on Sat 11th Sep 2010 15:34 UTC in reply to "Speed is fine"
lemur2 Member since:
2007-02-17

Now I'm using 4.0b5 - UI got much faster (since it's written in JavaScript it means their fixes work)


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.

Reply Score: 1

RE: Speed is fine
by Neolander on Sat 11th Sep 2010 16:54 UTC in reply to "Speed is fine"
Neolander Member since:
2010-03-08

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.

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

Reply Score: 2

Linux
by Elv13 on Sat 11th Sep 2010 18:18 UTC
Elv13
Member since:
2006-06-12

Just upgraded from B5 64bit -> B6pre 64bit... It is a -lot- slower than b5, switching back, submitting bug.

Reply Score: 2

Startup Speed Still Shitty
by JeeperMate on Mon 13th Sep 2010 00:23 UTC
JeeperMate
Member since:
2010-06-12

Don't have to say more, the title says it all.

Reply Score: 1

Ming / Mingw-w64
by fithisux on Mon 13th Sep 2010 18:33 UTC
fithisux
Member since:
2006-01-22

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

Reply Score: 2