Adding metrics to track browser launches per primary/secondary profile. Adding metrics to track n...

chrome/browser/profiles/profile_metrics.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/profiles/profile_metrics.h"
 
 #include "base/file_path.h"
 #include "base/logging.h"
 #include "base/metrics/histogram.h"
 #include "chrome/browser/browser_process.h"
@@ skipping 189 matching lines @@
                             NUM_PROFILE_TYPE_METRICS);
 }
 
 void ProfileMetrics::LogProfileSwitchGaia(ProfileGaia metric) {
   if (metric == GAIA_OPT_IN)
     LogProfileAvatarSelection(AVATAR_GAIA);
   UMA_HISTOGRAM_ENUMERATION("Profile.SwitchGaiaPhotoSettings",
                             metric,
                             NUM_PROFILE_GAIA_METRICS);
 }
+
+void ProfileMetrics::LogProfileLaunch(FilePath& profile_path) {
+  UMA_HISTOGRAM_ENUMERATION("Profile.LaunchBrowser",
+                            GetProfileType(profile_path),
+                            NUM_PROFILE_TYPE_METRICS);
+}
+
+void ProfileMetrics::LogNumberOfProfiles(ProfileTime startup) {
+  ProfileManager* manager = g_browser_process->profile_manager();

[Ilya Sherman, 2011/12/09 01:50:47]

I think accessing g_browser_process directly is discouraged, as there are
various subtleties, like needing to be sure to only access it from the main
thread.  I think there's a wrapper accessor somewhere that's recommended to be
used instead -- don't quite remember where that lives, though, atm.

[Miranda Callahan, 2011/12/09 14:01:02]

Using g_b_p is definitely to be avoided (for threading reasons, and because it's
often a thin veneer over a global variable pattern), but it's the standard way
of grabbing the profile_manager through a static method -- I think it's fine
here. You can DCHECK for the ui thread if there are threading concerns.

[rpetterson, 2011/12/09 21:22:09]

Since this function was only called from the ProfileManager, I've fixed it to
pass in the ProfileManager.  GetProfileType is a bit harder to fix, but I've
verified that all of th functions which use GetProfileType are only called on
the UI thread and added a DCHECK to the function. I've also added a comment
indicating such.

+  size_t number_of_profiles =
+      manager->GetProfileInfoCache().GetNumberOfProfiles();
+  if (startup == TIME_STARTUP) {
+    UMA_HISTOGRAM_COUNTS_100("Profile.NumberOfProfilesOnStartup",
+                             number_of_profiles);
+  } else {
+    UMA_HISTOGRAM_COUNTS_100("Profile.NumberOfProfilesOnAddDelete",

[jar (doing other things), 2011/12/09 04:57:13]

Perhaps a better name here would be:
NumberOfProfilesBeforeAddOrDelete

[rpetterson, 2011/12/09 21:22:09]

Changed to NumberOfProfilesAfterAddOrDelete (since the metric is logged at the
end of the Add and Delete functions).

+                             number_of_profiles);
+  }
+}