Linked by David Adams on Wed 3rd Aug 2011 16:50 UTC, submitted by _xmv
Mozilla & Gecko clones Mozilla Firefox has been listening to recent memory complains, and as a side effect tested the browser's scalability to the extreme with memshrink's improvements. The results are shocking: For 150 tabs open using the test script, Firefox nightly takes 6 min 14 on the test system, uses 2GB and stays responsive. For the same test, Chrome takes 28 min 55 and is unusable during loading. An optimized version of the script has been made for Chrome as an attempt to work-around Chrome's limitations and got an improved loading time of 27 min 58, while using 5GB of memory.
Thread beginning with comment 483638
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Comment by Praxis
by kaiwai on Thu 4th Aug 2011 13:41 UTC in reply to "RE[6]: Comment by Praxis"
kaiwai
Member since:
2005-07-06

That's exactly what the previously linked to blog was discussing. The issue was that memory got highly fragmented, so that even when a tab was closed and the memory freed a lot of it stayed around because there were 1 or 2 chunks still in use by the browser UI in that chunk of memory.

FF7 addresses that issue by moving all the browser UI memory into it's own chunks separate from the page content, and they saw massive improvements.

Of course, that wasn't the only problem and they are still going through lots of new ones, but perhaps before you talk about how they should start going after low hanging fruit you should do the research to find out that's exactly what they are doing.

Also, as far as the image decoding goes - i think the new plan is to leave them uncompressed for 10 seconds, after that the cache gets flushed. I think they have to be decompressed for things like scrolling, so even a fast decode is going to be slow if you have to do it 100 times a second.


That is all very well and good but it still doesn't address the fact that non-Windows users are treated like second class citizens; high CPU utilisation, lack of NPAPI pepper extensions (which leads to craptastic Flash performance when compared to the plugin running with Safari), then there is responsiveness issues, lack of hardware acceleration, the various Mac OS X specific bugs with the only excuse "well, its a problem with Mac OS X" (ignoring the fact that other browser developers don't seem to have the same problems).

Like I've said, I really do want to see a viable alternative to Safari on Mac OS X but the complete lack of any drive to make Firefox on Mac OS X a first class citizen equal to that of Windows makes it a non-starter for me. Visualise this, I'm sitting here saying, "hey Firefox I really want to use your browser but you're not treating the platform I like using as a equal to Windows" with the reply back from Firefox developers being 'fuck off and leave us alone" - delightful!

Reply Parent Score: 2

RE[8]: Comment by Praxis
by jacquouille on Thu 4th Aug 2011 13:59 in reply to "RE[7]: Comment by Praxis"
jacquouille Member since:
2006-01-02


That is all very well and good but it still doesn't address the fact that non-Windows users are treated like second class citizens; high CPU utilisation


Huh? Without more specifics I can't reply to that. But most Firefox developers use non-Windows platforms, I'd say by decreasing order it's Mac, then Linux, then Windows. So when they profile and optimize stuff, more often than not it's on Mac or Linux.

lack of NPAPI pepper extensions (which leads to craptastic Flash performance when compared to the plugin running with Safari)


I actually don't know what these are but the main guy working on NPAPI is full time on Mac... so I don't think it's an afterthought. File a bug maybe?

then there is responsiveness issues


Specifics?

lack of hardware acceleration


On Mac there has been compositing acceleration since Firefox 4. Content acceleration is not yet available on Mac as there is no Direct2D equivalent there. Direct2D means that on Windows, the hard work is already done for us, that's why Windows got content acceleration first.

On Linux, there's been XRender content acceleration for a long time, but it's not always great. Compositing acceleration is still disabled by default as due to texture_from_pixmap weirdness it's harder there than on other platforms, but there's a good chance to finally have it on by default in Firefox 9. Content acceleration by OpenGL is still not available for same reasons as on Mac.

Content acceleration on Mac and Linux is on the radar, follow the Azure project. Whenever it gets either a OpenGL or Skia backend, that will give us that.

Reply Parent Score: 2

RE[9]: Comment by Praxis
by kaiwai on Sat 6th Aug 2011 01:51 in reply to "RE[8]: Comment by Praxis"
kaiwai Member since:
2005-07-06

Huh? Without more specifics I can't reply to that. But most Firefox developers use non-Windows platforms, I'd say by decreasing order it's Mac, then Linux, then Windows. So when they profile and optimize stuff, more often than not it's on Mac or Linux.


If that is the case then they're doing a horrible job as programmers - the performance is horrible, lack of integration, out of place GUI etc.

I actually don't know what these are but the main guy working on NPAPI is full time on Mac... so I don't think it's an afterthought. File a bug maybe?


According to this: https://wiki.mozilla.org/NPAPI:Pepper

Mozilla is not interested in or working on Pepper at this time. See the Chrome Pepper pages.


Which now points to: http://code.google.com/p/ppapi/

It allows the plugin greater access to things such as hardware acceleration - Flash for example on Snow Leopard and higher (which has NPAPI Pepper extensions) uses Core Animation for example to speed up performance and reduce CPU utilisation.

Specifics?


Running heavy under a load. It comes back to the fact that they use XUL which could have been avoided had they had a small core and then built a native GUI on top of that rather than trying to write one GUI and cater it to the lowest common denominator.

On Mac there has been compositing acceleration since Firefox 4. Content acceleration is not yet available on Mac as there is no Direct2D equivalent there. Direct2D means that on Windows, the hard work is already done for us, that's why Windows got content acceleration first.

On Linux, there's been XRender content acceleration for a long time, but it's not always great. Compositing acceleration is still disabled by default as due to texture_from_pixmap weirdness it's harder there than on other platforms, but there's a good chance to finally have it on by default in Firefox 9. Content acceleration by OpenGL is still not available for same reasons as on Mac.

Content acceleration on Mac and Linux is on the radar, follow the Azure project. Whenever it gets either a OpenGL or Skia backend, that will give us that.


QuartzGL has existed and can be used on a per-application basis - there are ways to accelerate the content but Mozilla developers so far have been unwilling to dedicate the same amount of resources to Mac OS X as they do when it comes to their Windows builds.

Btw, there is nothing special about Direct2D/DirectWrite, you could do the very same thing using OpenGL - it would require more code but it is doable but it raises the greater question why wasn't there any move to create an API layer that sat on DirectX/OpenGL that delivered hardware support on all platforms at the same time?

Again, I look at the official Mozilla blog and again I see nothing in the wake of the Lion release, no information on the role that OpenGL 3.2 will play in future development, no mention about the enhanced sandboxing technology included in Lion, no mention of Xcode 4.2 moving 100% to LLVM and the role that'll play in future Firefox builds. So not only is there an issue with product that is neglected there is a complete lack of communication with the wider enthusiast community.

Reply Parent Score: 2