Closed Bug 516331 Opened 15 years ago Closed 13 years ago

mac OS performance regression with decode-on-draw switched on

Categories

(Core :: Graphics: ImageLib, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bholley, Assigned: bholley)

Details

(Whiteboard: [decodeondraw])

On saturday, I landed decode-on-draw (bug 435296). Windows saw a 9% Tp4 win, Mac OS saw a 17% Tp4 regression, and linux saw no Tp4 change. Clearly, the Mac numbers are scary.

We initially thought it was related to the strategy implemented in bug 512435 being pessimal in a synthetic Tp situation. To experiment, Joe and I closed the tree and pushed a patch (well, a patch and a followup) that immediately kicked off decode when the first data became available. In other words, we were using all of the new code and machinery, but forcing a "decode-on-load" strategy. Unfortunately, the numbers didn't seem to change.

I then pushed 2 patches. 1 to set gDecodeOnDraw=PR_FALSE,gDiscardable=PR_TRUE, and a second to set gDecodeOnDraw=PR_FALSE,gDiscardable=PR_FALSE. The rationale for the second patch was that setting gDecodeOnDraw to false (by itself) _should_ be very similar in performance to the "instant request strategy" that had no effect. If gDiscardable is also set to false, we skip storing source data altogether, so the code paths change a lot.

Unfortunately, there was a Tp4 freeze with the first patch (half on half off), which I'm going to file a bug for shortly. However, the second patch fixed the regression, so we landed it as bug 516311.

Thus, decode-on-draw and discarding are both switched off on trunk. This bug is for figuring out the mac os perf issue and hopefully turning it back on.
Whiteboard: [decodeondraw]
Hopefully fixed the Tp4 freeze with off/on in bug 516486. Pushed to try in 856728ef02d0, so maybe we'll see numbers soon.
the code in bug 517091 looks promising. Waiting on numbers from try.
According to try bug 517091 should do the trick. I just pushed it to central, but we won't see the results immediately because we don't want to re-enable discarding until we fix the flickering issues.

It would also be nice to have a look at bug 502694 and bug 517119, but those don't have to happen immediately since we've always lived with them (ie, they aren't regressions).

I'll resolve this fixed once we turn discarding back on and verify that there aren't problems on central.
As far as I can tell on try, there's no longer any performance penalty of activating the discarding machinery (the most I see is 1%). Resolving this as fixed.
(In reply to comment #4)
> As far as I can tell on try, there's no longer any performance penalty of
> activating the discarding machinery (the most I see is 1%). Resolving this
> as fixed.

Actually resolving it this time, one year later. ;-)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.