Last Comment Bug 516331 - mac OS performance regression with decode-on-draw switched on
: mac OS performance regression with decode-on-draw switched on
Status: RESOLVED FIXED
[decodeondraw]
:
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Bobby Holley (busy)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-13 22:13 PDT by Bobby Holley (busy)
Modified: 2011-08-01 14:15 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Bobby Holley (busy) 2009-09-13 22:13:40 PDT
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.
Comment 1 Bobby Holley (busy) 2009-09-14 13:21:59 PDT
Hopefully fixed the Tp4 freeze with off/on in bug 516486. Pushed to try in 856728ef02d0, so maybe we'll see numbers soon.
Comment 2 Bobby Holley (busy) 2009-09-16 16:29:54 PDT
the code in bug 517091 looks promising. Waiting on numbers from try.
Comment 3 Bobby Holley (busy) 2009-09-19 12:38:48 PDT
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.
Comment 4 Bobby Holley (busy) 2010-07-02 10:33:19 PDT
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.
Comment 5 Bobby Holley (busy) 2011-08-01 14:15:47 PDT
(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. ;-)

Note You need to log in before you can comment on or make changes to this bug.