Tweak validate() to check less as the size of the hash grows.

Tweak validate() to check less as the size of the hash grows.

This makes working with a non-trivial SkTDynamicHash less painful in Debug
builds.  validate() is skipped in Release, so this has no effect there.

BUG=

Committed: http://code.google.com/p/skia/source/detail?r=13121

[mtklein, 2014-01-16 15:09:28]

This is what I'd like to do instead of converting validate to its own test. 
Thoughts?

[bsalomon, 2014-01-16 15:54:47]

It seems OK for the current code. I have a small concern that someday this class
may be changed in a way that makes the current cutoff no longer sensible.

https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h
File src/core/SkTDynamicHash.h (right):

https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h#ne...
src/core/SkTDynamicHash.h:107: SKTDYNAMICHASH_CHECK(count == fCount);
won't this fail if fCount is very large?

[mtklein, 2014-01-16 16:01:45]

Would you be more comfortable with a timer-based approach?  Do we have a
microsecond timer?

https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h
File src/core/SkTDynamicHash.h (right):

https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h#ne...
src/core/SkTDynamicHash.h:107: SKTDYNAMICHASH_CHECK(count == fCount);
On 2014/01/16 15:54:48, bsalomon wrote:
> won't this fail if fCount is very large?

How large?  count and fCount are both ints (as are fCapacity and fDeleted), so
they should fit at least 2B entries before we have a problem.  If we ever make a
hash table with 2B entries, I'd be quite surprised: even if we were just mapping
ints to ints, that's 16G of RAM consumed by one table.

[mtklein, 2014-01-16 16:11:06]

On 2014/01/16 16:01:45, mtklein wrote:
> Would you be more comfortable with a timer-based approach?  Do we have a
> microsecond timer?
> 
> https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h
> File src/core/SkTDynamicHash.h (right):
> 
>
https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h#ne...
> src/core/SkTDynamicHash.h:107: SKTDYNAMICHASH_CHECK(count == fCount);
> On 2014/01/16 15:54:48, bsalomon wrote:
> > won't this fail if fCount is very large?
> 
> How large?  count and fCount are both ints (as are fCapacity and fDeleted), so
> they should fit at least 2B entries before we have a problem.  If we ever make
a
> hash table with 2B entries, I'd be quite surprised: even if we were just
mapping
> ints to ints, that's 16G of RAM consumed by one table.

Have another look?

[bsalomon, 2014-01-16 16:16:56]

On 2014/01/16 16:11:06, mtklein wrote:
> On 2014/01/16 16:01:45, mtklein wrote:
> > Would you be more comfortable with a timer-based approach?  Do we have a
> > microsecond timer?
> > 
> > https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h
> > File src/core/SkTDynamicHash.h (right):
> > 
> >
>
https://codereview.chromium.org/140753003/diff/1/src/core/SkTDynamicHash.h#ne...
> > src/core/SkTDynamicHash.h:107: SKTDYNAMICHASH_CHECK(count == fCount);
> > On 2014/01/16 15:54:48, bsalomon wrote:
> > > won't this fail if fCount is very large?
> > 
> > How large?  count and fCount are both ints (as are fCapacity and fDeleted),
so
> > they should fit at least 2B entries before we have a problem.  If we ever
make
> a
> > hash table with 2B entries, I'd be quite surprised: even if we were just
> mapping
> > ints to ints, that's 16G of RAM consumed by one table.
> 
> Have another look?

lgtm

[commit-bot: I haz the power, 2014-01-17 17:29:31]

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

[commit-bot: I haz the power, 2014-01-17 17:55:16]

Change committed as 13121