cc: Add tile pool to tile manager.

cc: Add tile pool to tile manager.

This patch pools unused tiles in tile manager and hands
them out before allocating new tiles.

[vmpstr, 2013-10-24 22:53:55]

Hey,

I'm not sure if this patch is really worth landing, but please take a look.

Cons are:
- It adds a somewhat iffy change to base/memory/ref_counted
- It adds another constant to tile manager
- Uses a bit more memory (ram)

Pros:
- Better performance on invalidation. Here's the before and after:

Before patch (but with extra perftests):
[ RUN      ] PictureLayerTilingPerfTest.Invalidate
*RESULT invalidation: 1x1= 39863 runs/s
*RESULT invalidation: 5x5= 5502 runs/s
*RESULT invalidation: 15x15= 803 runs/s
*RESULT invalidation: 25x50= 154 runs/s
*RESULT invalidation: 50x50= 44 runs/s

After patch:
[ RUN      ] PictureLayerTilingPerfTest.Invalidate
*RESULT invalidation: 1x1= 56261 runs/s (+40%)
*RESULT invalidation: 5x5= 7553 runs/s (+37%)
*RESULT invalidation: 15x15= 1106 runs/s (+38%)
*RESULT invalidation: 25x50= 152 runs/s (-1%)
*RESULT invalidation: 50x50= 46 runs/s (+4%)

Note that it might seem like a big number, but we're really talking about 1x1
going from 25 microseconds to 17 microseconds. That is, it's pretty fast as is
already. 15x15 might be worth it (going from 1.24ms -> 0.9ms)

[reveman, 2013-10-25 13:27:38]

On 2013/10/24 22:53:55, vmpstr wrote:
> Hey,
> 
> I'm not sure if this patch is really worth landing, but please take a look.
> 
> Cons are:
> - It adds a somewhat iffy change to base/memory/ref_counted
> - It adds another constant to tile manager
> - Uses a bit more memory (ram)
> 
> Pros:
> - Better performance on invalidation. Here's the before and after:
> 
> Before patch (but with extra perftests):
> [ RUN      ] PictureLayerTilingPerfTest.Invalidate
> *RESULT invalidation: 1x1= 39863 runs/s
> *RESULT invalidation: 5x5= 5502 runs/s
> *RESULT invalidation: 15x15= 803 runs/s
> *RESULT invalidation: 25x50= 154 runs/s
> *RESULT invalidation: 50x50= 44 runs/s
> 
> After patch:
> [ RUN      ] PictureLayerTilingPerfTest.Invalidate
> *RESULT invalidation: 1x1= 56261 runs/s (+40%)
> *RESULT invalidation: 5x5= 7553 runs/s (+37%)
> *RESULT invalidation: 15x15= 1106 runs/s (+38%)
> *RESULT invalidation: 25x50= 152 runs/s (-1%)
> *RESULT invalidation: 50x50= 46 runs/s (+4%)
> 
> Note that it might seem like a big number, but we're really talking about 1x1
> going from 25 microseconds to 17 microseconds. That is, it's pretty fast as is
> already. 15x15 might be worth it (going from 1.24ms -> 0.9ms)

Is this just heap allocation overhead or is there something more to it?

[vmpstr, 2013-10-25 18:34:38]

> Is this just heap allocation overhead or is there something more to it?

AFAIK it's mostly heap allocation. There might be a component of initializing
tile/managed state/tile versions as well since we're skipping some of that as
well, but I was actually thinking of adding full clear as well in order to avoid
any side effects

[reveman, 2013-10-25 18:53:55]

On 2013/10/25 18:34:38, vmpstr wrote:
> > Is this just heap allocation overhead or is there something more to it?
> 
> AFAIK it's mostly heap allocation. There might be a component of initializing
> tile/managed state/tile versions as well since we're skipping some of that as
> well, but I was actually thinking of adding full clear as well in order to
avoid
> any side effects

If there's some state that doesn't need to be initialized when reusing tiles
maybe it also doesn't need to be initialized in the first place?

I don't think removing the heap allocations is worth it if an invalidation size
of 25x50 is enough to make it an insignificant improvement.

[vmpstr, 2013-10-28 17:35:40]

On 2013/10/25 18:53:55, David Reveman wrote:
> On 2013/10/25 18:34:38, vmpstr wrote:
> > > Is this just heap allocation overhead or is there something more to it?
> > 
> > AFAIK it's mostly heap allocation. There might be a component of
initializing
> > tile/managed state/tile versions as well since we're skipping some of that
as
> > well, but I was actually thinking of adding full clear as well in order to
> avoid
> > any side effects
> 
> If there's some state that doesn't need to be initialized when reusing tiles
> maybe it also doesn't need to be initialized in the first place?
> 
> I don't think removing the heap allocations is worth it if an invalidation
size
> of 25x50 is enough to make it an insignificant improvement.

Just to note that's 25x50 tiles, not pixels. But I agree that this might be
complicating the code for not that much benefit. Re initialization: I think most
of the work here is default constructor things that we rely on (like
TilePriority), so I doubt we can justify removing it.

I'll keep this open just for reference, in case we find another good use of
using RefCountedManaged with some sort of pooling. Feel free to remove yourself
from the reviewers, so it doesn't clutter your inbox :)