Timothy Nikkel (:tnikkel) Reporter
	Description • 14 years ago

Bug 572680 seems to have caused an increase in memory usage. Specifically rev  b5f727a62c7c or 0fa683b7233d. See bug 598466 comment 104.

	Joe Drew (not getting mail)
	Comment 1 • 14 years ago

Blocking on the investigation. Markus, if you don't have time to do this just assign it back to me.

	Markus Stange [:mstange] Assignee
	Comment 2 • 14 years ago

This was the change that regressed performance by setting EXTEND_PAD more often than necessary, which was fixed in bug 600476. If painting with EXTEND_PAD needs more memory, that might explain it...

Ed, can you test whether fixing bug 600476 inverted the memory increase?

Nightly before: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-11-29-03-mozilla-central/
Nightly after: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-11-30-03-mozilla-central/

	Ed Morley [:emorley]
	Comment 3 • 14 years ago

Using the newer 90 tab profile from bug 598466 comment 97...

2010-08-13--97188fb7b44a [last known good]: 524/548/690
2010-08-13--b5f727a62c7c [first known bad]: 605/630/776

Now the two builds linked above... 
[both with methodjit.content=false, to avoid the methodjit increase introduced since then]
2010-11-29--nightly [pre patch]: 789/811/962
2010-11-30--nightly [post patch]: 731/751/910

Now the baseline usage was higher (due to two other memory increases after the one caused by bug 572680, even ignoring the methodjit one!), but if that is ignored, memory usage dropped by ~60MB, but had originally gone up by ~80MB (for 90 tabs). This may just be random variations/other issues at work (eg other changes in the pushlog for the linked builds), I'm not sure.

For reference, the full pushlog for those nightlies linked above is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5f9204fe5cd5&tochange=837d7b346a64

Maybe a more accurate way of testing is taking the first known bad revision (m-c rev b5f727a62c7c) and making a tryserver build with just the EXTEND_PAD patch (from bug 600476) added and nothing else?

	Markus Stange [:mstange] Assignee
	Comment 4 • 14 years ago

(In reply to comment #3)
> Maybe a more accurate way of testing is taking the first known bad revision
> (m-c rev b5f727a62c7c) and making a tryserver build with just the EXTEND_PAD
> patch (from bug 600476) added and nothing else?

Good idea, I've done that. The builds will appear here:
http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mstange@themasta.com-3f3da8d56c63/

	Ed Morley [:emorley]
	Comment 5 • 14 years ago

I've just run the three relevant builds (last good, first bad, first bad but with patch added) again with the 90 tab testcase, with the results:

2010-08-13--97188fb7b44a: 533/557/702
2010-08-13--b5f727a62c7c: 598/621/769
2010-08-13--b5f727a62c7c--with EXTEND patch from bug 600476: 532/558/703

Therefore looks like this issue was indeed fixed as part of bug 600476, which landed on m-c on 29th Nov. So presume this bug can be marked as a dupe of that bug?

Oh well, guess it didn't hurt to check to see if this memory increase still existed, least we know for sure it doesn't now!

	Joe Drew (not getting mail)
	Comment 6 • 14 years ago

Hooray!