Adds some histograms from various omnibox queries. I'm doing this as

chrome/browser/autocomplete/history_quick_provider.cc

Index: chrome/browser/autocomplete/history_quick_provider.cc
diff --git a/chrome/browser/autocomplete/history_quick_provider.cc b/chrome/browser/autocomplete/history_quick_provider.cc
index af0148cd4ecfe5926f55c31c71a0fc44e73f7179..890c509c994082accb9feae3bb6b50b79968ce2b 100644
--- a/chrome/browser/autocomplete/history_quick_provider.cc
+++ b/chrome/browser/autocomplete/history_quick_provider.cc
@@ -7,7 +7,10 @@
 #include "base/basictypes.h"
 #include "base/i18n/break_iterator.h"
 #include "base/logging.h"
+#include "base/metrics/histogram.h"
+#include "base/string_number_conversions.h"
 #include "base/string_util.h"
+#include "base/time.h"
 #include "base/utf_string_conversions.h"
 #include "chrome/browser/history/history.h"
 #include "chrome/browser/history/in_memory_url_index.h"
@@ -62,7 +65,16 @@ void HistoryQuickProvider::Start(const AutocompleteInput& input,
   // someone unloads the history backend, we'll get inconsistent inline
   // autocomplete behavior here.
   if (GetIndex()) {
+    base::TimeTicks start_time = base::TimeTicks::Now();
     DoAutocomplete();
+    if (input.text().size() < 6) {
+      base::TimeTicks end_time = base::TimeTicks::Now();
+      std::string name = "HistoryQuickProvider.QueryIndexTime." +
+          base::IntToString(input.text().size());
+      scoped_refptr<base::Histogram> counter = base::Histogram::FactoryGet(

[jar (doing other things), 2011/03/14 20:30:21]

nit/concern: This is all correct... and even makes the code thread safe.... but
you are incurring a perf cost.  The macro used a static to avoid that problem
(at the cost of a static... which is a problem in multi-threaded code!).  If you
are concerned about performance, you should have a switch in here for each of
the 6 cases.

The recurring perf involved is:
a) acquisition of a central lock.
b) find operation in a map.
c) mess with a smart pointer on acquisition and release.

The lock is probably the big cost, but the find operation may be working on a
map having about 400+ histogram names.

I haven't tried to quantify this cost.... if this is temporary... then don't
sweat it.  If this is long term (destined for stable??) then you might want to
<smile> histogram how long it takes to do this stuff, and be sure you're not
hurting too much (use the macro form to do that uber histogram).

+          name, 1, 1000, 50, base::Histogram::kUmaTargetedHistogramFlag);
+      counter->Add((end_time - start_time).InMilliseconds());
+    }
     UpdateStarredStateOfMatches();
   }
 }