Add UMA histograms to MHTML save operations.

tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index db79a3ce5c1c80b78b99517e17a4c6ee11bfab69..305c06305892c4359e276b814f268c96ca99af33 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -25514,6 +25514,71 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram
+    name="MhtmlGeneration.AllRenderersMainThreadTimeForFrameTreeSerialization"
+    units="ms">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time spent by the main threads of all involved render processes while
+    serializing the frame tree of a page being saved to MHTML.

[Ilya Sherman, 2016/09/24 02:53:52]

Is this summed over renderer processes?  How would someone go about interpreting
this value, and distinguishing "one renderer is affected a lot" vs. "many are
affected a bit"?  Is that measured by some of the other histograms below?  I
think the answer is: It's measured by
""MhtmlGeneration.RendererMainThreadTimeForFrameSerialization".  It would be
nice if these histograms had more similar names.  I'd suggest using more dots in
the names -- something like
"MhtmlGeneration.FrameSerialization.RendererMainThreadTime" and
"MhtmlGeneration.FrameTreeSerialization.RendererMainThreadTime".  Or some other
scheme that makes sense to you -- just something that has more obvious parallels
than the current names.

[carlosk, 2016/09/27 21:07:29]

Yes, values are collected on the many renders used for saving one page, sent
back to the browser which then adds all of them together and report to this
metric.
Yes, that is the relation between those histograms. And I agree a better naming
scheme would make the relationships clearer. I followed another logic for the
naming though so let me know WDYT.

+  </summary>
+</histogram>
+
+<histogram name="MhtmlGeneration.BrowserWaitTimeForFrameSerialization"
+    units="ms">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time the browser process waited on a single frame serialization by a render
+    processes while saving a page into MHTML.
+  </summary>
+</histogram>
+
+<histogram name="MhtmlGeneration.BrowserWaitTimeForFrameTreeSerialization"
+    units="ms">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Total time the browser process waited on all frame serializations by their
+    respective render processes while saving a page into MHTML.

[Ilya Sherman, 2016/09/24 02:53:51]

Is this a sum over MhtmlGeneration.BrowserWaitTimeForFrameSerialization, or can
the operations be done in parallel?  If they can be done in parallel, what are
the semantics of the wait time for just one frame?

[carlosk, 2016/09/27 21:07:29]

Yes, this is the sum of those for one save operation. They can't currently be
done in parallel as they are written to file directly by the renderer so they
must happen in order.

This measurement is useful in contrast to
MhtmlGeneration.AllRenderersMainThreadTimeForFrameTreeSerialization because it
can show us how much IPC handling waiting time there is versus the time we
actually occupy the renderer main thread.

+  </summary>
+</histogram>
+
+<histogram name="MhtmlGeneration.FullFrameEncodingTime" units="microseconds">

[Ilya Sherman, 2016/09/24 02:53:51]

What is the importance of the word "full" in this name?  Are partial frames also
encoded?

[carlosk, 2016/09/27 21:07:29]

This is in fact in consequence of the histogram below,
MhtmlGeneration.FullFrameSerializationTime.

I chose to add the "full" to try to clarify that this "serialization" includes
all the frame's contents -- HTML and CSS + image resources -- in comparison to
each of those things considered in isolation, which are reported in the other
histograms. 

But indeed, it is not necessary if we'd like to keep names as concise as
possible.

+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time taken to encode into MTHML the full serialized contents of a frame.
+  </summary>
+</histogram>
+
+<histogram name="MhtmlGeneration.FullFrameSerializationTime"
+    units="microseconds">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time taken to serialize the full contents of a frame, including HTML and
+    resources.
+  </summary>
+</histogram>
+
+<histogram name="MhtmlGeneration.FullPageSavingTime" units="ms">

[Ilya Sherman, 2016/09/24 02:53:52]

What's the difference between a "page" and "frame tree"?  Are these the same
concept?

[carlosk, 2016/09/27 21:07:29]

The "page" version includes a few more things when compared to the "frame tree",
like opening and closing the MHTML file and a few more things.

My adding the "full" again here now makes me think that's in fact confusing. I
left it only here and removed it from the "frame" versions above.

+  <owner>carlosk@chromium.org</owner>
+  <summary>The total time it took to save a page into an MHTML file.</summary>
+</histogram>
+
+<histogram name="MhtmlGeneration.RendererMainThreadTimeForFrameSerialization"
+    units="ms">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time spent by the renderer main thread while serializing one frame of a page
+    being saved to MHTML.
+  </summary>
+</histogram>
+
+<histogram name="MhtmlGeneration.WritingToDiskTime" units="ms">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time spent writing MHTML serialized data to the file on disk.
+  </summary>
+</histogram>

[Ilya Sherman, 2016/09/24 02:53:51]

Would it be appropriate to group all of these histograms under the
PageSerialization category, e.g. as "PageSerialization.MhtmlGeneration.*"?

[carlosk, 2016/09/27 21:07:29]

That would certainly make it clearer that these are all related. I don't
appreciate all that much the much longer names they get but I think the former
reason is more important. So done.

+
 <histogram name="Mist.SwitchResult" enum="MistSwitchResult">
   <owner>benchan@chromium.org</owner>
   <summary>
@@ -40241,6 +40306,27 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="PageSerialization.CSSSerializationTime" units="microseconds">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time spent serializing a top level CSS resource (including embedded
+    &quot;sub&quot; CSS and images).
+  </summary>
+</histogram>
+
+<histogram name="PageSerialization.HtmlSerializationTime" units="microseconds">
+  <owner>carlosk@chromium.org</owner>
+  <summary>
+    Time taken to generate HTML from an exiting frame contents and serialize it
+    (without sub-resources).
+  </summary>
+</histogram>
+
+<histogram name="PageSerialization.ImageSerializationTime" units="microseconds">
+  <owner>carlosk@chromium.org</owner>
+  <summary>Time spent serializing an image resource.</summary>
+</histogram>

[Ilya Sherman, 2016/09/24 02:53:52]

If there are multiple images on a page, presumably there will be multiple
entries emitted to this histogram, right?  Is there something that measures the
overall time to serialize a full page?  If not, is that something that would be
useful to measure?

(I think that the MhtmlGeneration histograms might measure this, but it's not
totally clear to me what the relationship between the "PageSerialization" and
the "MhtmlGeneration" histograms is.)

[carlosk, 2016/09/27 21:07:29]

Correct, the Image and Css histograms may be created many times even for a
single frame. I assume these metrics will be useful for a future change we
envision to split the serialization work in more than one renderer main thread
task.

There are metrics that encompass these times you are referring to. Given the
name changes I also updated the description to clarify "what encompasses what".
I tried to explain that in the description:

| I created two
| new categories for these metrics: MhtmlGeneration for code written
| specifically for MHTML saving, and PageSerialization for the more
| generic serialization pieces.

+
 <histogram name="Parser.AppendBytesDelay" units="ms">
   <owner>csharrison@chromium.org</owner>
   <summary>