Early out from CleanUpUnusedImageDecodeTasks().

Early out from CleanUpUnusedImageDecodeTasks().

If we have no image decode tasks, we don't need to do all the tile
and layer management to identify which are unnecessary. 200% speedup
on manage_tiles_*_0, 25% speedup on manage_tiles_*_100.

Thanks to Sami for the suggestion.

BUG=282412
R=reveman@chromium.org,vmpstr@chromium.org
CC=skyostil@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=220607

[tomhudson, 2013-08-30 14:52:37]

PTAL.

On Android I see similar perftest improvement as on desktop: 2-3x when for
manage_tiles_*_0, 10-20% for _100.

[reveman, 2013-08-30 15:34:17]

nice, lgtm

[commit-bot: I haz the power, 2013-08-30 15:37:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/tomhudson@chromium.org/23495013/1

[vmpstr, 2013-08-30 16:32:42]

lgtm2! This is really nice. I wonder though if there's a way we can get the set
of used layers quicker even if we don't early out. My concern is that with a
single layer that has one picture on it, we'll be iterating all of the tiles
just to construct a set with one layer id. Maybe we can do something like the
dirty flag for prioritized tile set here as well?

[tomhudson, 2013-08-30 16:39:25]

On 2013/08/30 16:32:42, vmpstr wrote:
> lgtm2! This is really nice. I wonder though if there's a way we can get the
set
> of used layers quicker even if we don't early out. My concern is that with a
> single layer that has one picture on it, we'll be iterating all of the tiles
> just to construct a set with one layer id. Maybe we can do something like the
> dirty flag for prioritized tile set here as well?

Absolutely, or this strikes me as data that we probably could maintain
dynamically.
Could we essentially "refcount" layers? Then this function just scans
image_decode_tasks_ looking for those with a layer whose count is 0?

But if you look at the perf results on the bug, this has fallen to < 1% of CPU
time, so we might want to take the easy win and focus on other bottlenecks
instead of adding more complexity here trying for something incremental.

[vmpstr, 2013-08-30 16:48:33]

On 2013/08/30 16:39:25, tomhudson wrote:
> On 2013/08/30 16:32:42, vmpstr wrote:
> > lgtm2! This is really nice. I wonder though if there's a way we can get the
> set
> > of used layers quicker even if we don't early out. My concern is that with a
> > single layer that has one picture on it, we'll be iterating all of the tiles
> > just to construct a set with one layer id. Maybe we can do something like
the
> > dirty flag for prioritized tile set here as well?
> 
> Absolutely, or this strikes me as data that we probably could maintain
> dynamically.
> Could we essentially "refcount" layers? Then this function just scans
> image_decode_tasks_ looking for those with a layer whose count is 0?
> 
> But if you look at the perf results on the bug, this has fallen to < 1% of CPU
> time, so we might want to take the easy win and focus on other bottlenecks
> instead of adding more complexity here trying for something incremental.

It kinda goes back to what you said about optimizing for perftests instead of
optimizing for real world though, no? I mean a single lazy pixel ref is enough
to "defeat" the early out. I'm not saying this is bad or anything, I think this
is an easy win and definitely should go in. I'm just saying while here we might
wanna try something smarter in terms of computing the layers. I think the
refcount approach you proposed is actually pretty easy to implement (a hash map
of layer id -> count) and then we can update that in register/unregister tile,
and clean anything up with count 0 in this same function. I might of course be
missing some edge case :)

[commit-bot: I haz the power, 2013-08-30 17:59:29]

Change committed as 220607