Allocate memory in SkTDynamicHash on first use.

Allocate memory in SkTDynamicHash on first use.

This eliminates any dynamic allocation for hash tables that are never used.
This helps SkPicture, where some tables (SkPaint) are almost always used, but
some rarely (SkMatrix) or never (SkRegion).

This also removes the (as yet unimportant) ability for the hash table to
shrink.  This makes resizing harder to reason about, so I'd like to leave it
out until we see a need.

BUG=skia:1850
Committed: http://code.google.com/p/skia/source/detail?r=13051

[mtklein, 2014-01-13 17:15:47]

hashes drop off the null-picture-record profile, as hoped.

[reed1, 2014-01-13 17:38:04]

1. is it possible to just create a new hash efficiently from an existing one...
as a way to simulate shrinking?

2. we should probably just store matrices inline in the opcodes, rather than
creating a heap.

both of these questions are not intended for this CL

lgtm

[mtklein, 2014-01-13 17:43:52]

On 2014/01/13 17:38:04, reed1 wrote:
> 1. is it possible to just create a new hash efficiently from an existing
one...
> as a way to simulate shrinking?
> 
> 2. we should probably just store matrices inline in the opcodes, rather than
> creating a heap.
> 
> both of these questions are not intended for this CL
> 
> lgtm

1. Sure thing.  That's effectively what resize() does, and resize() works as
written to either increase or decrease capacity.  The only thing I want to avoid
here is the complexity around deciding WHEN to shrink.

2. Yep.  We haven't bothered to change them only because they're small potatoes
next to paints.

[commit-bot: I haz the power, 2014-01-13 17:49:56]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@google.com/136403004/30001

[commit-bot: I haz the power, 2014-01-13 18:28:17]

Change committed as 13051