Support saving browser metrics to disk and reading them during next run.

base/metrics/persistent_histogram_allocator.h

 // Copyright 2016 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.
 
 #ifndef BASE_METRICS_HISTOGRAM_PERSISTENCE_H_
 #define BASE_METRICS_HISTOGRAM_PERSISTENCE_H_
 
 #include <memory>
 
 #include "base/atomicops.h"
@@ skipping 223 matching lines @@
 
   // Gets a pointer to the global histogram allocator.
   static GlobalHistogramAllocator* Get();
 
   // This access to the persistent allocator is only for testing; it extracts
   // the current allocator completely. This allows easy creation of histograms
   // within persistent memory segments which can then be extracted and used
   // in other ways.
   static std::unique_ptr<GlobalHistogramAllocator> ReleaseForTesting();
 
+  // Stores a pathname to which the contents of this allocator should be saved
+  // in order to persist the data for a later use.
+  void SetPersistentLocation(FilePath location);

[Ilya Sherman, 2016/04/19 00:57:46]

nit: Are FilePaths usually passed by copy or by const ref?

[bcwhite, 2016/04/19 16:33:38]

I've seen it both ways.  If I make this a ref then I have to do a copy during
the implementation whereas it is currently std::move'd.

I think this is more efficient because FilePaths are often created on-the-fly
and so the compiler can just move the result of that creation into the
parameter, perhaps without ever needing to create the actual object in memory.

[Ilya Sherman, 2016/04/20 07:12:14]

There was recently a thread on chromium-dev about a similar topic, but for
strings [1].  The conclusion there was to prefer passing by const-ref.  I'd
think the same would apply to FilePath params.  Does that make sense?

[1]
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/ZoAfW7GXUVI

[bcwhite, 2016/04/20 16:47:45]

Interesting.  Better to pass-by-ref for maintainability reasons.  Done.

+
+  // Writes the internal data to a previously set location. This is generally
+  // called when a process is exiting from a section of code that may not know
+  // the filesystem. The data is written in an atomic manner. The return value
+  // indicates success.
+  bool WritePersistentLocation();

[Ilya Sherman, 2016/04/19 00:57:46]

nit: Perhaps "WriteTo" rather than just "Write"?

[bcwhite, 2016/04/19 16:33:38]

Done.

+
  private:
   friend class StatisticsRecorder;
 
   explicit GlobalHistogramAllocator(
       std::unique_ptr<PersistentMemoryAllocator> memory);
 
   // Import new histograms from the global histogram allocator. It's possible
   // for other processes to create histograms in the active memory segment;
   // this adds those to the internal list of known histograms to avoid creating
   // duplicates that would have to be merged during reporting. Every call to
   // this method resumes from the last entry it saw; it costs nothing if
   // nothing new has been added.
   void ImportHistogramsToStatisticsRecorder();
 
   // Import always continues from where it left off, making use of a single
   // iterator to continue the work.
   Iterator import_iterator_;
 
+  // The location to which the data should be persisted.
+  FilePath persistent_location_;

[Ilya Sherman, 2016/04/19 00:57:46]

nit: Can this be const?

[bcwhite, 2016/04/19 16:33:37]

Const values have to be set in the constructor.  This isn't because that
information isn't known until the higher layers get started.

+
   DISALLOW_COPY_AND_ASSIGN(GlobalHistogramAllocator);
 };
 
 }  // namespace base
 
 #endif  // BASE_METRICS_HISTOGRAM_PERSISTENCE_H_