Add histograms to track localStorage size and load time by size.

webkit/dom_storage/dom_storage_cached_area.cc

Index: webkit/dom_storage/dom_storage_cached_area.cc
diff --git a/webkit/dom_storage/dom_storage_cached_area.cc b/webkit/dom_storage/dom_storage_cached_area.cc
index 6b20886bcb27d9894d4cbb3fb06175a08b3923a9..5ef4784ce1c7baddf5f2ffd1acc78cd0ee734247 100644
--- a/webkit/dom_storage/dom_storage_cached_area.cc
+++ b/webkit/dom_storage/dom_storage_cached_area.cc
@@ -154,10 +154,29 @@ void DomStorageCachedArea::Prime(int connection_id) {
       connection_id, &values,
       base::Bind(&DomStorageCachedArea::OnLoadComplete,
                  weak_factory_.GetWeakPtr()));
+  base::TimeDelta time_to_prime = base::TimeTicks::Now() - before;
   UMA_HISTOGRAM_TIMES("LocalStorage.TimeToPrimeLocalStorage",
-                      base::TimeTicks::Now() - before);
+                      time_to_prime);
   map_ = new DomStorageMap(dom_storage::kPerAreaQuota);
   map_->SwapValues(&values);
+
+  size_t local_storage_size_kb = MemoryBytesUsedByCache() / 1024;
+  // Track localStorage size, from 0-6MB. Note that the maximum size should be
+  // 5MB, but we add some slop since we want to make sure the max size is always
+  // above what we see in practice, since histograms can't change.

[michaeln, 2013/02/12 00:38:15]

lgtm modulo the paranoia about 'too large'

... but it might not be measuring exactly what you want. This will measure the
time to prime the renderer's cache w/o regard for the state of the browser's
cache. From when we spoke, sounded like you were interested in measuring the
time to prime the browser's cache.

Maybe we'll see two spikes in the distribution, a shorter time for when the
browsers cache is already primed, and a longer time for when its not.

[willchan no longer on Chromium, 2013/02/12 00:42:22]

Is there a way to instrument this in a way so I can isolate out the browser and
renderer samples?

[michaeln, 2013/02/12 01:17:12]

Not from this class|method, we can't distinguish here what the state of the
browser is.

See DomStorageArea::InitialImportIfNeeded() for where the browser's cache (a
map) is loaded out of the db. 

+  UMA_HISTOGRAM_CUSTOM_COUNTS("LocalStorage.LocalStorageSizeInKB",
+                              local_storage_size_kb,
+                              0, 6 * 1024, 50);

[michaeln, 2013/02/12 00:38:15]

What happens if we give this macro a value that's 'too large'? If the answer is
it crashes, probably worth a call to std::min.

[willchan no longer on Chromium, 2013/02/12 00:42:22]

It doesn't crash, we just lose granularity. What's the maximum value returned by
MemoryBytesUsedByCache()? I wasn't sure how exact it was.

[michaeln, 2013/02/12 01:17:12]

sgtm!
There is some room for an origin to go over budget. I didn't remember by what
amount exactly so I dug around in the code.

// In the browser process we allow some overage to
// accommodate concurrent writes from different renderers
// that were allowed because the limit imposed in the renderer
// wasn't exceeded.
const size_t kPerAreaOverQuotaAllowance = 100 * 1024;

+  if (local_storage_size_kb < 100) {
+    UMA_HISTOGRAM_TIMES("LocalStorage.TimeToPrimeLocalStorageUnder100KB",
+                        time_to_prime);
+  } else if (local_storage_size_kb < 1000) {
+    UMA_HISTOGRAM_TIMES("LocalStorage.TimeToPrimeLocalStorageUnder1MB",
+                        time_to_prime);
+  } else {
+    UMA_HISTOGRAM_TIMES("LocalStorage.TimeToPrimeLocalStorageUnder5MB",

[jar (doing other things), 2013/02/11 19:27:51]

Based on the above logic, the histograms are really:
Storage <100KB
vs
100KB < storage < 1MB
vs
1MB < storage < 5MB

As a result, the names of teh histogram are a tad deceptive.

You might either change the names, or adjust the logic to not have "else"
clauses, and just use "if" statements.

YMMV.

[willchan no longer on Chromium, 2013/02/12 00:42:22]

Good point. I'll rename once I settle the above stuff with Michael.

+                        time_to_prime);
+  }
 }
 
 void DomStorageCachedArea::Reset() {