Remove histogram from GraphicsLayerUpdater::rebuildTree

Remove histogram from GraphicsLayerUpdater::rebuildTree

This CL removes a histgram from GraphicsLayerUpdater::rebuildTree. This
histogram accounts for 9.2% of the time spent in
GraphicsLayerUpdater::rebuildTree and 1.6% of the total compositing update in
Polymer's calculator.

R=ojan@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169908

[eseidel, 2014-03-24 23:41:42]

Do we not have a perf test which covers this change?  I'm concerned we'll
regress this again if we don't.  Or perhaps when you land this the perf sheriffs
will rejoice?

[ojan, 2014-03-24 23:41:59]

lgtm

[commit-bot: I haz the power, 2014-03-24 23:42:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/210093005/1

[ojan, 2014-03-24 23:42:51]

On 2014/03/24 23:41:42, eseidel wrote:
> Do we not have a perf test which covers this change?  I'm concerned we'll
> regress this again if we don't.  Or perhaps when you land this the perf
sheriffs
> will rejoice?

In theory the key_silk_cases benchmark should hit this, although I'm skeptical
that benchmark will show small improvements like this.

[commit-bot: I haz the power, 2014-03-24 23:55:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-24 23:55:58]

Try jobs failed on following builders:
  tryserver.blink on mac_blink_rel

[abarth-chromium, 2014-03-25 02:38:02]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-03-25 02:38:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/210093005/1

[abarth-chromium, 2014-03-25 02:41:49]

On 2014/03/24 23:41:42, eseidel wrote:
> Do we not have a perf test which covers this change?  I'm concerned we'll
> regress this again if we don't.  Or perhaps when you land this the perf
sheriffs
> will rejoice?

The calculator is a bit different than the content in the Silk page set because
it just has a ton of RenderLayers, many more than are composited at any given
time.  We can add something like that to the Silk page set to make sure we don't
add too much per-RenderLayer work to the compositing update.

Are we even running the Silk page set on bots?  I couldn't find any graphs for
it on chromeperf.appspot.com...

[commit-bot: I haz the power, 2014-03-25 02:48:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 02:48:10]

Try jobs failed on following builders:
  tryserver.blink on mac_blink_compile_dbg

[esprehn, 2014-03-25 02:50:17]

Build failures look like they might be you:

../../third_party/WebKit/Source/core/rendering/compositing/GraphicsLayerUpdater.h:55:17:error:
private field 'm_renderView' is not used [-Werror,-Wunused-private-field]

[abarth-chromium, 2014-03-25 02:57:31]

clang is too smart!

[abarth-chromium, 2014-03-25 02:57:34]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-03-25 02:57:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/210093005/20001

[commit-bot: I haz the power, 2014-03-25 03:00:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 03:00:46]

Try jobs failed on following builders:
  tryserver.blink on blink_presubmit

[esprehn, 2014-03-25 03:03:55]

The CQ bit was checked by esprehn@chromium.org

[commit-bot: I haz the power, 2014-03-25 03:04:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/210093005/20001

[commit-bot: I haz the power, 2014-03-25 04:00:28]

Change committed as 169908

[ojan, 2014-03-25 04:23:11]

On 2014/03/25 02:41:49, abarth wrote:
> On 2014/03/24 23:41:42, eseidel wrote:
> > Do we not have a perf test which covers this change?  I'm concerned we'll
> > regress this again if we don't.  Or perhaps when you land this the perf
> sheriffs
> > will rejoice?
> 
> The calculator is a bit different than the content in the Silk page set
because
> it just has a ton of RenderLayers, many more than are composited at any given
> time.  We can add something like that to the Silk page set to make sure we
don't
> add too much per-RenderLayer work to the compositing update.
> 
> Are we even running the Silk page set on bots?  I couldn't find any graphs for
> it on http://chromeperf.appspot.com...

Hmmm...we were. But it seems to have gotten busted:
https://chromeperf.appspot.com/report?masters=ChromiumPerf&bots=android-gn%2C...

Filed https://code.google.com/p/chromium/issues/detail?id=355952.