Add metrics for calculating precision/recall of link navigation pre-connect triggers.

chrome/browser/net/predictor.h

Index: chrome/browser/net/predictor.h
diff --git a/chrome/browser/net/predictor.h b/chrome/browser/net/predictor.h
index 3e6a2e3287e7eba6526540600aa4a1c7618b6b56..e58e51635d4a6a13fe3a28e1339b4ab64010a91b 100644
--- a/chrome/browser/net/predictor.h
+++ b/chrome/browser/net/predictor.h
@@ -238,7 +238,16 @@ class Predictor {
                                UrlInfo::ResolutionMotivation motivation,
                                int count);
 
-  void RecordPreconnectNavigationStats(const GURL& url);
+  // May be called from either the IO or UI thread and will PostTask

[jar (doing other things), 2013/08/01 22:56:47]

nit: (personal?) I think it is a bad pattern to protect methods with a callback
to the right thread if you happen to be on the wrong thread when calling.  

I guess you could argue that you compact some amount of code (the post-task
call), but I think that folks should know which thread they are on, and not be
blind to the implications of such calls.

I'll ask others... but my personal preference is to avoid this pattern.  

If you really have a bunch of folks calling Foo() from both the IO thread and
from the UI thread (and want to save code?), you *could* have a
FooFromUIThread() vs a FooFromIOThread().  That would at least hint to the
reader that you might be on the wrong thread.. and this call might need to be
posted etc.

[kouhei (in TOK), 2013/08/02 06:18:03]

I changed so that callers PostTask to IOThread.

+  // to the IO thread if necessary.
+  void RecordPreconnectTrigger(const GURL& url);
+
+  void RecordPreconnectNavigationStat(const std::vector<GURL>& url_chain,
+                                      bool is_subresource);
+
+  // May be called from either the IO or UI thread and will PostTask

[jar (doing other things), 2013/08/01 22:56:47]

nit: same comment on pattern as above.

[kouhei (in TOK), 2013/08/02 06:18:03]

Done.

+  // to the IO thread if necessary.
+  void RecordLinkNavigation(const GURL& url);
 
   // ------------- End IO thread methods.
 
@@ -453,6 +462,10 @@ class Predictor {
   // continue with them shortly (i.e., it yeilds and continues).
   void IncrementalTrimReferrers(bool trim_all_now);
 
+  void RecordPreconnectTriggerOnIOThread(const GURL& url);
+
+  void RecordLinkNavigationOnIOThread(const GURL& url);

[jar (doing other things), 2013/08/01 22:56:47]

So you have this method... it is just IMO nicer to expose it, let callers use
their knowledge to "call the right flavor," and then DCHECK that it was done
correctly.  This also means we don't waste time doing the check in production
code needlessly.

[kouhei (in TOK), 2013/08/02 06:18:03]

Done.

+
   // ------------- End IO thread methods.
 
   scoped_ptr<InitialObserver> initial_observer_;
@@ -509,7 +522,8 @@ class Predictor {
   // The time when the last preconnection was requested to a search service.
   base::TimeTicks last_omnibox_preconnect_;
 
-  TimedCache recent_preconnects_;
+  class PreconnectUsage;
+  scoped_ptr<PreconnectUsage> preconnect_usage_;
 
   // For each URL that we might navigate to (that we've "learned about")
   // we have a Referrer list. Each Referrer list has all hostnames we might