Open Bug 583069 Opened 11 years ago Updated 8 years ago

Runnables might be really slow on mac

Categories

(Core :: Widget: Cocoa, defect)

x86
macOS
defect
Not set
normal

Tracking

()

People

(Reporter: bholley, Unassigned)

References

Details

Vlad asked me to file this based on my experiences 10 months ago with decode-on-draw.

When we landed the new decode-on-draw machinery, we got a 17% Tp4 regression on mac (nothing on linux, and improvement on windows). We filed bug 516331 about this.

After some investigation, I determined that the cause was bug 517091. Basically, every time we'd call RequestDecode() on an image from a call-stack that originated in a decoder, we'd post a Runnable to call RequestDecode() from a fresh stack. This wasn't actually necessary most of the time, since RequestDecode() only has an effect if we're not already decoding (an uncommon case). So that patch was an optimization that seemed to fix things.

Note that on trunk right now, discarding and decode-on-draw are switched off, so RequestDecode() is a no-op. So you won't be able to see the Tp4 hit by reversing the patch from bug 517091 unless you also enable image.mem.discardable and/or image.mem.decodeondraw.

This is all also as of last september. Who knows what's changed since then? Still, if Runnables are in fact expensive on mac, we should fix that.
Do we have any profile data from a test that posts lots of runnables to see where time is spent?
Component: XPCOM → Widget: Cocoa
QA Contact: xpcom → cocoa
This sounds similar to bug 606937.
Depends on: 606937
You need to log in before you can comment on or make changes to this bug.