Add a field trial for using lower sqlite cache sizes.

chrome/browser/history/history_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/history_database.h"
 
 #include <algorithm>
 #include <set>
 #include <string>
 
 #include "base/command_line.h"
 #include "base/file_util.h"
 #include "base/metrics/histogram.h"
 #include "base/rand_util.h"
 #include "base/string_util.h"
 #include "chrome/browser/diagnostics/sqlite_diagnostics.h"
+#include "chrome/browser/history/history_field_trial.h"
 #include "sql/transaction.h"
 
 #if defined(OS_MACOSX)
 #include "base/mac/mac_util.h"
 #endif
 
 namespace history {
 
 namespace {
 
@@ skipping 44 matching lines @@
                                       const FilePath& bookmarks_path) {
   // Set the exceptional sqlite error handler.
   db_.set_error_delegate(GetErrorHandlerForHistoryDb());
 
   // Set the database page size to something a little larger to give us
   // better performance (we're typically seek rather than bandwidth limited).
   // This only has an effect before any tables have been created, otherwise
   // this is a NOP. Must be a power of 2 and a max of 8192.
   db_.set_page_size(4096);
 
-  // Increase the cache size. The page size, plus a little extra, times this
-  // value, tells us how much memory the cache will use maximum.
-  // 6000 * 4MB = 24MB
-  // TODO(brettw) scale this value to the amount of available memory.
-  db_.set_cache_size(6000);
+  if (HistoryFieldTrial::IsLowMemFieldTrial()) {
+    db_.set_cache_size(64);
+  } else {
+    // Increase the cache size. The page size, plus a little extra, times this
+    // value, tells us how much memory the cache will use maximum.
+    // 6000 * 4MB = 24MB
+    // TODO(brettw) scale this value to the amount of available memory.
+    db_.set_cache_size(6000);
+  }

[Scott Hess - ex-Googler, 2011/10/24 19:15:27]

Yeah, I'm with jar, this range is pretty huge.  I suspect that 6000 was not
providing much utility (most likely a small part of it was interior nodes, with
a ton of randomly-selected other pages), but since pages are atomic, when you
start to get so small as 64 you might start to see problems with thrashing.  It
might make sense to first prove a case for going below 500 (already saving 20M),
and worry about going further at that point if benefits haven't been capped.

 
   // Note that we don't set exclusive locking here. That's done by
   // BeginExclusiveMode below which is called later (we have to be in shared
   // mode to start out for the in-memory backend to read the data).
 
   if (!db_.Open(history_name))
     return sql::INIT_FAILURE;
 
   // Wrap the rest of init in a tranaction. This will prevent the database from
   // getting corrupted if we crash in the middle of initialization or migration.
@@ skipping 239 matching lines @@
       "WHERE id IN (SELECT id FROM segment_usage WHERE time_slot > 0);");
 
   // Erase all the full text index files. These will take a while to update and
   // are less important, so we just blow them away. Same with the archived
   // database.
   needs_version_17_migration_ = true;
 }
 #endif
 
 }  // namespace history