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 483487
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Comment by Praxis
by smitty on Thu 4th Aug 2011 00:22 UTC in reply to "RE[5]: Comment by Praxis"
smitty
Member since:
2005-10-13

How about this, start with the low hanging fruit - when someone closes a tab how about reclaiming the memory then you might actually find that many of the complaints regarding Firefox would evaporate. The problem has always been the inability for memory to be reclaimed after a tab or window has been closed but the Firefox developers keep denying what is really the problem in favour of spending time in trivialities.

Btw, I once again expect Firefox 7 to be an entirely giant disappointment on Mac OS X just as previous versions have shown - once again unless you're a Windows user you're pretty much shit out of luck if you expect something half decent on your platform of choice.

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.

Edited 2011-08-04 00:25 UTC

Reply Parent Score: 4

RE[7]: Comment by Praxis
by kaiwai on Thu 4th Aug 2011 13:41 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