SkTDynamicHash doesn't immediately recycle slots for removed entries,
but instead just marks them as deleted.
The only way to reclaim deleted slots currently is when an exponential
grow/resize is triggered.
A consequence of this is that the capacity/allocated storage can grow
indefinitely when the hash is long-lived and churning -- even if the
number of active entries is small/stable.
To prevent this, I propose we only grow the capacity when the number of
active slots constitutes a significant portion. Otherwise (when most
slots are deleted), we trigger a "purge" (resize to the same capacity)
to clear the tombstones.
Bug: chromium:832482
Change-Id: Iefdcd7439f7d62ac021e176b71007d207c8bc876
Reviewed-on: https://skia-review.googlesource.com/122082
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
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
R=tomhudson@chromium.org, reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/136403004
git-svn-id: http://skia.googlecode.com/svn/trunk@13051 2bbb7eff-a529-9590-31e7-b0007b416f81
- add validate()
- make add() and remove() strict
- fill in maybeShrink()
- make grow and shrink thresholds configurable.
- fix issue where we were getting filled with deleted items - we need to count them as occupied when determining if we should grow
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/22571010
git-svn-id: http://skia.googlecode.com/svn/trunk@10677 2bbb7eff-a529-9590-31e7-b0007b416f81
