Would it make sense to log it both the old way and new way for a release and see what the deviation is?

Even by just changing the behavior we should see pretty clearly what the change looks like when it hits the stable channel. It'll presumably approach the final value following the kind of S-curve we currently see when things reach stable.

Yeah, and we can generate data internally during the transition that splits the two releases out.  It would be a bunch of extra complexity to try to preserve the old busted approach along with the new one, I don't think it's worth it.

Maybe we'll want to add some sort of indicator to the chromestatus timeline though, just to reduce the cost of people being surprised / digging into the discontinuity.

Just having milestone markers on the graphs would be nice in general.

Going into this (and  issue 236262 ) in detail, it doesn't seem THAT bad to try to keep the existing metrics around while we transition to new ones with more correct semantics.  The metrics are definitely going to change dramatically (see  issue 597963 ) and it'll probably take a little time to ensure we have confidence in them so it makes some sense to have overlap.

See https://codereview.chromium.org/2023903003/ for a WIP patch along these lines

Renaming Blink>Architecture to Blink>Internals

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ef896c91bab517924c6658af5f71ee3d8511b3b8

commit ef896c91bab517924c6658af5f71ee3d8511b3b8
Author: rbyers <rbyers@chromium.org>
Date: Fri Aug 26 18:27:24 2016

Minor UseCounter clean-ups

Remove the mostly useless CountBits abstraction and better align the
generic feature and CSS property usage tracking.  Also a couple other
minor cleanups and comments warning of outstanding issues.

BUG= 597963 

Review-Url: https://codereview.chromium.org/2284503002
Cr-Commit-Position: refs/heads/master@{#414753}

[modify] https://crrev.com/ef896c91bab517924c6658af5f71ee3d8511b3b8/third_party/WebKit/Source/core/frame/UseCounter.cpp
[modify] https://crrev.com/ef896c91bab517924c6658af5f71ee3d8511b3b8/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/ef896c91bab517924c6658af5f71ee3d8511b3b8/third_party/WebKit/Source/core/page/Page.cpp
[modify] https://crrev.com/ef896c91bab517924c6658af5f71ee3d8511b3b8/third_party/WebKit/Source/core/workers/WorkerGlobalScope.cpp
[modify] https://crrev.com/ef896c91bab517924c6658af5f71ee3d8511b3b8/third_party/WebKit/Source/core/workers/WorkerGlobalScope.h

WIP here: https://codereview.chromium.org/2290733002

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/631a26b68f615f8282efba7ded2a6f4fac236482

commit 631a26b68f615f8282efba7ded2a6f4fac236482
Author: rbyers <rbyers@chromium.org>
Date: Mon Sep 12 16:56:57 2016

Add new UseCounter metric

Adds a new UMA histogram "WebCore.UseCounter_TEST" which fixes the issue with
data loss on fast shutdown while temporarily preseving the original
semantics in the legacy "WebCore.FeatureObserver" histogram.

Also overhauls the tests to look directly at the histograms.

Note that the semantics of the new UseCounter are still under flux and
being validated, hence the '_TEST' suffix in the histogram name.  Once
validated it'll be renamed to simply WebCore.UseCounter and we will expect
to never change the semantics of the histogram again (without rename).

BUG= 597963 

Review-Url: https://codereview.chromium.org/2290733002
Cr-Commit-Position: refs/heads/master@{#417957}

[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/third_party/WebKit/Source/core/frame/PRESUBMIT.py
[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/third_party/WebKit/Source/core/frame/UseCounter.cpp
[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/third_party/WebKit/Source/core/frame/UseCounterTest.cpp
[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/third_party/WebKit/Source/core/workers/WorkerGlobalScope.cpp
[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/third_party/WebKit/Source/platform/testing/HistogramTester.cpp
[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/third_party/WebKit/Source/platform/testing/HistogramTester.h
[modify] https://crrev.com/631a26b68f615f8282efba7ded2a6f4fac236482/tools/metrics/histograms/histograms.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/705c8eb7fa3ee2ee19da9c78fdd8266108ae207e

commit 705c8eb7fa3ee2ee19da9c78fdd8266108ae207e
Author: dtapuska <dtapuska@chromium.org>
Date: Tue Sep 13 16:22:31 2016

Fix clang-cl release component build failure on windows.

Issue was caused in change:
https://codereview.chromium.org/2290733002

BUG= 597963 

Review-Url: https://codereview.chromium.org/2336253002
Cr-Commit-Position: refs/heads/master@{#418267}

[modify] https://crrev.com/705c8eb7fa3ee2ee19da9c78fdd8266108ae207e/third_party/WebKit/Source/core/frame/UseCounter.h

Landed the key changes, keeping open on M56 to track switching to the new counter.

Can chrome://histograms be updated to display the WebCore.UseCounter_TEST stats? (So that when you are developing a new histogram, you can see the actual count, rather than the old on-page-destruction-maybe count.)

That page is dynamic. So it should appear. The only problem is when a renderer's histogram counts are fetched from the browser. And that occurs as specific times. So you should reload the page you are monitoring so see the histogram counts change. 

chrome://histograms is dynamic? In my experience you have to reload the page to see any changes.

But you're right that it does show WebCore.UseCounter_TEST (I was stupidly only looking at the WebCore.FeatureObserver section). So ignore #18.

When switching to the new counter / final name, I should probably also go with "Blink.UseCounter" instead of "WebCore.UseCounter" (since that's where most blink-related histograms seem to go these days).

mgiuca, it's dynamic in that it's generated from data but it doesn't refresh automatically.

Everything on that page is current as far as the browser process is concerned.  However, metrics are only collected from child processes and merged into the browser process about every 30 minutes (on desktop).

Making the histograms page fetch all child histograms before displaying is non-trivial.  Feel free to voice your opinion in  issue #602295 .

#22: metrics are only collected from child processes and merged into the browser process about every 30 minutes (on desktop).

What? Are you sure? I generally see stats right away (after a refresh) from the renderers (though perhaps I'm only thinking of Android).

Positive.  But I forgot one:  It also gets collected when the child process exits.

The other thing to keep in mind is that the renderer can also trigger explicitly a push to the browser process of the metrics data, via RenderThreadImpl::UpdateHistograms() - so it's possible some other metrics end up triggering that while other don't.

Brian, question for you - if we switch to persistent histograms, do we regress in this area? (i.e. does UpdateHistograms() become a no-op for all histograms living in persistent memory - and thus we lose the mechanism to force update histograms from renderer side?)

Correct.  UpdateHistograms was to be removed eventually.

Another option would be to keep it around and have the IPC receiver trigger a local collection.

Moved the meta-level work to  issue 676837 .  The change for this issue is long-landed.

 Issue 293666  has been merged into this issue.