Add a field trial for using lower sqlite cache sizes.

chrome/browser/history/in_memory_database.cc

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/history/in_memory_database.h"
 
 #include "base/file_path.h"
 #include "base/logging.h"
 #include "base/metrics/histogram.h"
 #include "base/time.h"
 #include "base/utf_string_conversions.h"
 #include "build/build_config.h"
+#include "chrome/browser/history/history_field_trial.h"
 
 namespace history {
 
 InMemoryDatabase::InMemoryDatabase() : URLDatabase() {
 }
 
 InMemoryDatabase::~InMemoryDatabase() {
 }
 
 bool InMemoryDatabase::InitDB() {
@@ skipping 61 matching lines @@
   }
 
   // Copy URL data to memory.
   base::TimeTicks begin_load = base::TimeTicks::Now();
   if (!db_.Execute(
       "INSERT INTO urls SELECT * FROM history.urls WHERE typed_count > 0")) {
     // Unable to get data from the history database. This is OK, the file may
     // just not exist yet.
   }
   base::TimeTicks end_load = base::TimeTicks::Now();
-  UMA_HISTOGRAM_MEDIUM_TIMES("History.InMemoryDBPopulate",
-                             end_load - begin_load);
+  UMA_HISTOGRAM_MEDIUM_TIMES(
+      "History.InMemoryDBPopulate" + HistoryFieldTrial::GetGroupSuffix(),

[jar (doing other things), 2011/10/24 18:40:55]

There is a nicer(?) or at least common patterns for doing this.  Typically you
leave the existing histogram in place (so that it can be seen, unchanged), and
add a test for the existence of the field trial (saving it into a static).  IFF
the field trial is active, you can then use the MakeName() method to do the
concatenation.

[brettw, 2011/10/25 01:55:02]

I guess that sounds worse to my thinking. Wouldn't I want the old histogram name
to have a consistent meaning (in my case, the old cache sizes), rather than
doing a weighted average of people in and out of the trial?

[Scott Hess - ex-Googler, 2011/10/26 21:44:59]

Can you have it both ways?  Old histogram for non-trial users, new histogram for
trial users?

Doh.  I see what you mean - if not in the trial, you're appending string().

[jar (doing other things), 2011/10/27 00:23:55]

The usual pattern is to keep the old histogram unchanged....
and then have a set of histograms (generated from a single HISTOGRAM macro),
that are for the distinct field trial groups.

This way you have you cake (old clean histograms) and you eat it too (you have
user runs partitioned among the set of field trial histograms).

On 2011/10/26 21:44:59, shess wrote:

+      end_load - begin_load);
   UMA_HISTOGRAM_COUNTS("History.InMemoryDBItemCount", db_.GetLastChangeCount());
 
   {
     // This calculation should be fast (since it's on an in-memory DB with
     // an average of only 35 rows).
     sql::Statement visit_count(db_.GetUniqueStatement(
         "SELECT sum(visit_count) FROM urls"));
     if (visit_count && visit_count.Step()) {
       UMA_HISTOGRAM_COUNTS("History.InMemoryTypedUrlVisitCount",
                            visit_count.ColumnInt(0));
@@ skipping 42 matching lines @@
   CreateKeywordSearchTermsIndices();
 
   return true;
 }
 
 sql::Connection& InMemoryDatabase::GetDB() {
   return db_;
 }
 
 }  // namespace history