576615 - 50% idle cpu usage with image discarding enabled

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Bobby Holley (:bholley)]

Jo Hermans and Myzar were reporting this over at bug 563088 comment 12 and bug 563088 comment 13. Moving the discussion here so that we can keep track of it better.

Comment 1

[Bobby Holley (:bholley)]

I'm not about to easily reproduce this on my mac.

Jo and Myzar - since you guys are on windows, do you want to try profiling Firefox when it starts spiking CPU?

There are instructions for setting up and using xperf here:
https://developer.mozilla.org/en/Profiling_with_Xperf

If you download the newest version of xperf, you should be able to pretty easily set it up to connect to mozilla's debug symbol server, and then turn on profiling when you see the issue.

You can just turn it on with
xperf -on latency
(no need for the -stackwalk profile).

Also, I'm assuming here that you've triple-checked that whatever you're seeing does not happen with discarding off. ;-)

Thanks for all your help!

Comment 2

[Myzar]

Sorry i've attached it in the other bug, let me attach here too, i've no idea how to read it tho

Comment 3

[Myzar]

Attachment: Firefox Performance profiling

Comment 4

[Jo Hermans]

You can read the data with the xperfview command, which combines the data with the symbols to make it readable.

Comment 5

[Myzar]

Yes i've it opened with symbols loaded too, but i don't know what to look to find the problem . this is a screenshot from a trace with firefox process zombified after i quit it and refused to die

http://yfrog.com/f/eutracetj/

Comment 6

[Bobby Holley (:bholley)]

Interesting. Is there something underneath xul.dll? If not, those CPU usage numbers don't add up...

Looking at that trace I have a hunch as to what it might be. It looks like there's a lot of stuff in there related to blocking onload, which we do for images (see bug 512435). With discarding on, we get multiple sets of observer notifications for images. The ones after the first ones should definitely be no-ops, but there's some async machinery involved, so who knows - maybe they build up somehow.

As a test, I put together a patch that disables the onload blocking machinery for images. I've pushed it to try here:


When the builds are rolled, I'd be really interested for you to take a look and see if you still see the problem. When they're ready (in about an hour or so), they should appear here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-7b0b2dcc794f/

Comment 7

[Myzar]

there are windows dll only, xul.dll is the only firefox related

http://yfrog.com/mwtrace2j

I will try your test build when it's done and report

Comment 8

[Myzar]

Unfortunately i can't start the debug build it's giving me this error

Activation context generation failed  Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86"  could not be found. 

I don't have that dll and it's prolly installed with visual studio, i'll figure out tomorrow

Comment 9

[Bobby Holley (:bholley)]

(In reply to comment #8)
> Unfortunately i can't start the debug build it's giving me this error
> 

No need to use a debug build - just grab the regular win32 one (which will be most similar to what you're running with the nightlies).

Comment 10

[Myzar]

Sorry the win32 one was the last to be built on your try server, looks like you were right on the cause because it doesn't seem to happen anymore, i've even opened 10 tabs with facebook and i've started to scroll very fast, that was the easiest way to trigger the bug with onload blocking

Comment 11

[Bobby Holley (:bholley)]

(In reply to comment #10)
> Sorry the win32 one was the last to be built on your try server, looks like you
> were right on the cause because it doesn't seem to happen anymore, i've even
> opened 10 tabs with facebook and i've started to scroll very fast, that was the
> easiest way to trigger the bug with onload blocking

That's great to hear. Sounds like the onload blocking/unblocking triggered by discard redecodes is having a pretty significant performance impact. I've CCed bz with the hopes that he'll have some insight on this. It may be a bit before we get an actual fix together, but when we do I hope you can give it a test drive and make sure the problem doesn't crop up again.

Thanks a ton for reporting this and helping track it down!

Comment 12

[Bobby Holley (:bholley)]

Myzar & Jo - Do you have firebug installed? If so, can you reproduce without it?

Comment 13

[Jo Hermans]

No I don't. Clean profile.

Comment 14

[Myzar]

I don't too i've tried with a clean profile too

Comment 15

[Bobby Holley (:bholley)]

Alright, I've figured this bug out with the help of a lot of record-and-replay.

The cause of this bug is detailed in bug 579535. However, retained layers inadvertently fixed this when it landed last night. So as of the current nightlies, this problem should be gone.

Jo, Myzar - can you confirm?

Comment 16

[Jo Hermans]

Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre

Seems to be fixed, indeed.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Been a couple hours with discarding enabled and no troubles here either.

Comment 18

[Bobby Holley (:bholley)]

Awesome - Resolving fixed.

Thanks a ton for everyone's help on this. Props to Jo and Myzar for alpha-testing discarding, and to Ryan for catching this bug in a debugger with bz in the vicinity. ;-)

Comment 19

[Myzar]

it was a pleasure to help , wfm too now

Comment 20

[Danial Horton]

Only fixed for those using hardware acceleration.

if you disable hardware acceleration it uses 100% of a single core.