summaryrefslogtreecommitdiffstats
path: root/build
diff options
context:
space:
mode:
authorgavinp@chromium.org <gavinp@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-05-10 10:05:26 +0000
committergavinp@chromium.org <gavinp@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-05-10 10:05:26 +0000
commite6c0633bada8818d20008300e2efcba81c67788f (patch)
tree47075a8778f0d3b53e3315bda10c99f8d634c6b5 /build
parent79df93870043072b0f2bff6166b7070d9b028bad (diff)
downloadchromium_src-e6c0633bada8818d20008300e2efcba81c67788f.zip
chromium_src-e6c0633bada8818d20008300e2efcba81c67788f.tar.gz
chromium_src-e6c0633bada8818d20008300e2efcba81c67788f.tar.bz2
Add NEWCACHE method to IndexInitializeMethod histogram.
UMA histograms don't distinguish creating a new cache from rebuilding a new index due to a preexisting stale or corrupt index. This means that it's difficult to see how often the cache is restoring with a bad index, vs a new cache being created; and since lots of users start up the new simple backend everyday, we can't track bad indexes. This is not great; index restore/rebuild is slow, and we want to make sure it happens very rarely in practice. This adds a new value to the INITIALIZE_METHOD, so we can separate new caches from rebuilding indexes in existing caches. As well, we track how many entries are in our new index. This isn't expected to always be zero, since entries can be created asynchronously while or before the index is rebuilding. But it does provide a sanity check in case index files are being erased (not expected), as large values would show we're sometimes missing index files on mature caches. R=stevet,asvitkine@chromium.org BUG=None Review URL: https://chromiumcodereview.appspot.com/14890014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@199447 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'build')
0 files changed, 0 insertions, 0 deletions