User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110101 Firefox/4.0b9pre Build Identifier: firefox private bytes usage goes to 1.5Gb after loading: http://www.fusker.lv/index.php?lid=286341&offset=30&special=preview Reproducible: Always

That's because of all those huge images. They take a long time to load, a long time to decode, and they take a large amount of memory. This is perfectly normal, after waiting 10 secs, memory should be cleared again. The images will reappear in memory when needed, so if you scroll the page fast, you might end up with a lot of memory again. But after waiting 10 seconds, they should be gone again. I tried to set the image.mem.decodeondraw preference to true (delaying the actual decoding), but it didn't make any difference.

NB: URL is NSFW (multiple porn shoot images) Some results... (working set usage, all with noscript running, since don't really want to run random js from a porn site) Firefox 3.6.13: Peaks at ~950 mb after page load (even before scrolling), drops back to ~120MB if left idle. Firefox 4 latest nightly: Peaks at ~1GB after page load (even before scrolling), drops back to ~160MB if switched to another tab and then left idle. Chrome 10.0.612.3 dev: Initial usage ~190MB before scrolling, ~1100MB after, then drops back to ~190MB when left idle/switch to another tab and back. Scrolling less smooth than Firefox, presumably since images are not loaded into memory until during scrolling. Seems like usage is fairly consistent across the board - only difference is that Chrome doesn't hold onto the memory unless you are scrolling, but this makes scrolling less smooth, so pros/cons. Also, seems that Firefox 4 differs from 3.6.13 in that idle memory drop back to 100MB ish only occurs if that tab is not being shown. Not sure if this is an intentional behaviour change.

(In reply to comment #2) > NB: URL is NSFW (multiple porn shoot images) > > Seems like usage is fairly consistent across the board - only difference is > that Chrome doesn't hold onto the memory unless you are scrolling, but this > makes scrolling less smooth, so pros/cons. Also, seems that Firefox 4 differs > from 3.6.13 in that idle memory drop back to 100MB ish only occurs if that tab > is not being shown. Not sure if this is an intentional behaviour change. Joe will know.

I've tested this also on mobile fennec, and situation really bad there... On webkit I see image data downloaded in child process, but not encoded... and as result page loading is fast, and memory consumption on finish loading ~80Mb. On remote fennec I see memory consumption grows first in both processes, parent and child, also I noticed aggressive memory copy in mozilla::net::HttpChannelParent::OnDataAvailable, NS_ReadInputStreamToString

Given that bugs like bug 598466 are being promoted to avoid OOM crash bugs like bug 590674, would it perhaps make sense to also take a look at other potential OOM situations (like this bug) in more detail than they would otherwise? ie: Following on from comment 2, would a hybrid solution in-between the current Firefox implementation and the Chrome one, whereby normally all images are decoded initially (as happens currently with Firefox, and means much smoother scrolling than Chrome on the testcase URL), but only up to a certain memory usage limit, at which point the oldest decoded images are discarded more aggressively (and without needing to switch to another tab), a la Chrome?

It is intentional that we don't drop memory usage while the tab is in front, because it provides a better user experience on that web page. It's not clear what the desired outcome is from this bug. If someone has a clear desired outcome, please file that separately!

I guess important problem here is that in Chrome minimum memory usage is 190M, and in FF is 950 - 120 = 830... this is not very good

For future reference: similar issues are discussed in bug 683284 and related bugs.