Significant image memory regression since Fx36+ when hardware acceleration is disabled

NEW
Unassigned

Status

()

defect
P3
normal
4 years ago
9 months ago

People

(Reporter: dindog, Unassigned)

Tracking

(Depends on 1 bug, {memory-footprint, regression})

36 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted], )

Attachments

(1 attachment)

7.36 MB, application/x-compress-7z
Details
Reporter

Description

4 years ago
Reproduce proceed:

1. make sure "Use hardware acceleration when available" is UNCHECKED then restart Firefox
2. open
http://www.guanggoo.com/t/3085
3. scroll to the page, observe the memory consumption of Firefox. 

Result:

Firefox 35.0.1, Maximum Mem: ~350MB 
Firefox 36.0.4, Maximum Mem: ~1090MB
Reporter

Comment 1

4 years ago
typo correction:

Reproduce process, not proceed.
3. scroll to the bottom of the page

Comment 2

4 years ago
I did a memory report, and most of it is in images.

1,092,067,392 B (100.0%) -- explicit
├──1,018,888,736 B (93.30%) -- images
│  ├──1,018,861,936 B (93.30%) -- content/raster/used
│  │  ├─────34,160,880 B (03.13%) -- image(3264x2448, http://i2.tietuku.com/2dde8df42d46f24b.jpg)
│  │  │     ├──32,923,808 B (03.01%) -- unlocked
│  │  │     │  ├──31,961,168 B (02.93%) ── surface(3264x2448@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x424@0)/decoded-heap
│  │  │     └───1,237,072 B (00.11%) ── source
│  │  ├─────34,111,728 B (03.12%) -- image(3264x2448, http://i2.tietuku.com/0660ebb1d7734d8b.jpg)
│  │  │     ├──31,961,168 B (02.93%) ── locked/surface(3264x2448@0)/decoded-heap
│  │  │     ├───1,187,920 B (00.11%) ── source
│  │  │     └─────962,640 B (00.09%) ── unlocked/surface(566x425@0)/decoded-heap
│  │  ├─────34,046,192 B (03.12%) -- image(3264x2448, http://i2.tietuku.com/f16f004f04bc1cf7.jpg)
│  │  │     ├──32,923,808 B (03.01%) -- unlocked
│  │  │     │  ├──31,961,168 B (02.93%) ── surface(3264x2448@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     └───1,122,384 B (00.10%) ── source
│  │  ├─────26,345,792 B (02.41%) -- image(2845x2134, http://i2.tietuku.com/902394c6c8d959e8.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     ├─────888,912 B (00.08%) ── locked/surface(544x408@0)/decoded-heap
│  │  │     └─────208,976 B (00.02%) ── source
│  │  ├─────26,255,680 B (02.40%) -- image(2845x2134, http://i2.tietuku.com/f87ea5722dcdd948.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     ├─────893,008 B (00.08%) ── locked/surface(544x409@0)/decoded-heap
│  │  │     └─────114,768 B (00.01%) ── source
│  │  ├─────26,227,008 B (02.40%) -- image(2845x2134, http://i2.tietuku.com/939035bf8952ae47.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     ├─────888,912 B (00.08%) ── locked/surface(544x408@0)/decoded-heap
│  │  │     └──────90,192 B (00.01%) ── source
│  │  ├─────25,583,856 B (02.34%) -- image(2845x2134, http://i2.tietuku.com/a96a2c946dfbb9ba.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     └─────335,952 B (00.03%) ── source
│  │  ├─────25,559,280 B (02.34%) -- image(2845x2134, http://i2.tietuku.com/2c4dafc3b2e2c7bf.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x424@0)/decoded-heap
│  │  │     └─────311,376 B (00.03%) ── source
│  │  ├─────25,506,032 B (02.34%) -- image(2845x2134, http://i2.tietuku.com/48c50f388acd753b.jpg)
│  │  │     ├──25,247,904 B (02.31%) -- unlocked
│  │  │     │  ├──24,285,264 B (02.22%) ── surface(2845x2134@0)/decoded-heap
│  │  │     │  └─────962,640 B (00.09%) ── surface(566x425@0)/decoded-heap
│  │  │     └─────258,128 B (00.02%) ── source

and so on.

This mostly seems to be related to imagelib. Tentatively ni? seth.
Flags: needinfo?(seth)

Comment 3

4 years ago
If i set layers.async-pan-zoom.enabled= true , I cant reproduce this.

Comment 4

4 years ago
I reproduce the bug on Fx36 & Fx41, not for Fx35 & Fx41 with layers.async-pan-zoom.enabled=true. The same result.

I see the huge memory is automatically cleaned up after ~1min, to 161/234MB (working set/virtual memory), then 150/208MB. also cleaned up after "minimize memory" in about:memory.

Comment 5

4 years ago
*we hold alive some decoded image data even for tabs that are closed, for 60 seconds.* from it.
Depends on: 1123976

Updated

4 years ago
Duplicate of this bug: 1153572

Comment 7

4 years ago
Try to set image.mem.surfacecache.min_expiration_ms to 1000

Comment 8

3 years ago
verified 45.0.1
Since this appears to be an issue with image memory, I'm moving bug from the Memory Allocator to the ImageLib Bugzilla component.
Component: Memory Allocator → ImageLib
Summary: Significant memory performance regression since Fx36+ when HA is disabled → Significant image memory regression since Fx36+ when hardware acceleration is disabled
Hi reporter,

I have tested your issue on latest FF release (45.0.2) and latest Nightly build and could not reproduce it. I have unchecked "Use hardware acceleration when available" and after a restart, the browser didn't use more than 300 MB of memory(several tabs where opened). Firefox had the same behavior regardless if "layers.async-pan-zoom.enabled" was set to true or false.

Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).

Thanks,
Paul.
Flags: needinfo?(dindog)
I tested these are the numbers I see:

Firefox 35.0.1, Maximum Mem: ~600MB 
Firefox 36.0.4, Maximum Mem: ~1600MB
Current Firefox nightly, ~1000MB

So we regressed, and then improved, but didn't fix all of the regression.
Hi reporter,

Did a new profile or safe mode made any difference on the latest builds?

Thanks,
Paul.

Comment 13

3 years ago
(In reply to Timothy Nikkel (:tnikkel) from comment #11)
> I tested these are the numbers I see:
> 
> Firefox 35.0.1, Maximum Mem: ~600MB 
> Firefox 36.0.4, Maximum Mem: ~1600MB
> Current Firefox nightly, ~1000MB
> 
> So we regressed, and then improved, but didn't fix all of the regression.

that strange, i test it on ff45.0.2,i cant reproduce it whether HA is on or off .
Reporter

Comment 14

3 years ago
(In reply to Paul Pasca[:PoollyMcklayn] from comment #12)
> Hi reporter,
> 
> Did a new profile or safe mode made any difference on the latest builds?
> 
> Thanks,
> Paul.

I got some new discovery.  Not sure it should be discuss in a new bug report....

Test with the Nightly 48a1 2016-04-21 on Win10 64bit.

I didn't reproduce the bug at first, then I resized the frame of Firefox, the memory allocated to Firefox bumped up quickly, a few second later it reach 1100MB. CPU usage was high as well

This website will scale the image to fit the width of browser window, maybe Firefox try to resample the resized image in too small interval, GPU can take care it but not the case when it come to CPU?
Flags: needinfo?(dindog)
Hi reporter,

I'm still unable to reproduce your issue with the steps from your latest comment. Did a new profile or safe mode made any difference? If you are still reproducing this issue, could you please try to find a regression range using Mozregression tool?
Information on the tool is available at http://mozilla.github.io/mozregression/. Please don't hesitate to contact us if you encounter any problems.

Thanks,
Paul.
Flags: needinfo?(dindog)
Reporter

Comment 16

3 years ago
What do you mean can't reproduce the issue, you didn't have noticeable RAM different between 35.0.1 from later versions or the hardware acceleration part? 

It's easy reproduce

firefox -no-remote -safe-mode -profile d:\new_profile

Open the page, wait all image loaded, scroll to have some images into view, then resize Firefox windows, then Firefox CPU usage and memory consumption bump up quickly which you can't hardly notice it, it rise to over 1000MB in 20 second.

I am afraid using mozregression tool is not an option for me at them moment... My connection to mozilla ftp has been bad recently, nightly stay at April 22nd...

I hope Alice could reproduce it... he has been really good at locating regression commit.
Flags: needinfo?(dindog) → needinfo?(alice0775)

Comment 17

3 years ago
Did a new profile or safe mode made any difference?
Flags: needinfo?(dindog)

Comment 18

3 years ago
Posted file archive
Flags: needinfo?(alice0775)

Updated

3 years ago
Keywords: footprint

Comment 20

3 years ago
/*the last version with well perfomance (resize widows or scrool the page wont lead memory grown)*/
Dir 	2014-11-28-00-40-01-mozilla-aurora/ 	
	
/*not contain windows installer or zip */ 	
Dir 	2014-11-28-08-00-45-mozilla-aurora/
 		
/*not contain windows installer or zip */
Dir 	2014-11-28-08-05-23-mozilla-aurora/ 	
	
/*the first version with bad perfomance (resize widows or scrool the page will lead memory grown)*/ 
Dir 	2014-11-28-11-51-36-mozilla-aurora/

/*the last version with bad perfomance (resize widows or scrool the page will lead memory grown)*/ 
Dir 	2015-12-14-00-40-08-mozilla-aurora/

/*the first version fixed the bug PARTLY(resize widows will lead memory grown but scrool the page wont as Comment 14 )*/ 
Dir 	2015-12-14-12-22-42-mozilla-aurora/
Reporter

Comment 21

3 years ago
(In reply to Andre Klapper from comment #17)
> Did a new profile or safe mode made any difference?
No. It's tested with new profile and safe mode.

Sorry for the late reply, not available in weekdays. And thanks to Alice and FateRover narrowed down the commits.
Flags: needinfo?(dindog)
Whiteboard: [gfx-noted]

Updated

9 months ago
Flags: needinfo?(seth.bugzilla)
You need to log in before you can comment on or make changes to this bug.