All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=893818

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=e50e3cb183d63be9d10136ba40fa7c93bd555dcfe3b5a251ec4a9dd052368c25


Bot(s) for this bug's original alert(s):

linux-perf

rendering.desktop - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/109b4cd2e40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/109b4cd2e40000

Make ObserverList iteration 10~20 times faster. by tapted@chromium.org
https://chromium.googlesource.com/chromium/src/+/f59cdf0d304cd451e2507a13dd12da6f8fccaffb
percentage_smooth: 94.58 → 93.66 (-0.915)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

blink doesn't use base::ObserverList


This is probably r596476, not r596492 . I'll try re-running the pinpoint.

author	Hajime Hoshi <hajimehoshi@chromium.org>	Thu Oct 04 01:44:23 2018

Avoid using TaskObserver at MemoryCache

We want to avoid TaskObserver since this binds the current message
loop's default task runner and a class tightly.

This CL makes MemoryCache not be a TaskObserver and actual pruning is
deferred by posting a task. This changes the behavior that the pruning
task is enqueued to the end of the task runner. This should not affect
actual memory usages so much.

This CL also replaces the default task runner usages in the tests with
the test task runner since we also want to avoid the default task runner
in the test as much as possible.

Bug: 870606
Change-Id: I6865ffe2a02800b5106b6da8605e7624498d6316
Reviewed-on: https://chromium-review.googlesource.com/c/1258805

also showing improvements at https://chromeperf.appspot.com/group_report?sid=e50e3cb183d63be9d10136ba40fa7c93bd555dcfe3b5a251ec4a9dd052368c25 show 50 improved perf for rendering.desktop, some quite large, attached to this one small regression . They seem to have a larger bisect range though.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/119b4cd2e40000

r596498 is a possibility too. I think percentage_smooth is some scrolling benchmark.
 [PE] Fix caret visual rect and painting when scrolled

that CL adds some clipping, which might be expensive.

Re #c7 the clip is required for correctness.

I don't think my CL is related to the test for smooth scrolling.

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/119b4cd2e40000

Make ObserverList iteration 10~20 times faster. by tapted@chromium.org
https://chromium.googlesource.com/chromium/src/+/f59cdf0d304cd451e2507a13dd12da6f8fccaffb
percentage_smooth: 94.8 → 94.18 (-0.6216)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

 Issue 893797  has been merged into this issue.

This just looks like noise. See also https://bugs.chromium.org/p/chromium/issues/detail?id=866000#c14 - these suggest `rendering.desktop` is badly affected by unrelated stuff that's happening in the browser UI, and should be re-written not to draw things like loading throbbers.

I'll undupe  Issue 893797  in case there's something there.

Deleted: Screen Shot 2018-10-11 at 9.48.17 am.png 13.7 KB

	Screen Shot 2018-10-11 at 9.48.17 am.png 13.7 KB View Download

I'm bisecting a perf-improve for this showing up at

Chromium Commit Position range: 598251 - 598278 
V8 Commit Position: 668b404 
WebRTC Git Hash range: 0d8c100 - 5f35e96 

"just in case".. Maybe there's something there that helped filter out the noise more reliably.

Deleted: Screenshot from 2018-10-18 11-47-20.png 60.1 KB

	Screenshot from 2018-10-18 11-47-20.png 60.1 KB View Download

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/159ba1bce40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/159ba1bce40000

Recalc style from first to last sibling. by futhark@chromium.org
https://chromium.googlesource.com/chromium/src/+/a2bc49cf7603a49aa935fc20b1f212ad9487269c
percentage_smooth: 94.11 → 94.69 (+0.5748)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

futhark@chromium.org: FYI that's a pinpoint for a perf-improve :).

Well, actually a perf result going from noisy to less-noisy.

This is ChromiumPerf/linux-perf/rendering.desktop/percentage_smooth/css_transitions_new_element

r598275 is just

diff --git a/third_party/blink/renderer/core/dom/container_node.cc b/third_party/blink/renderer/core/dom/container_node.cc
index d313efc..f94b4d2 100644
--- a/third_party/blink/renderer/core/dom/container_node.cc
+++ b/third_party/blink/renderer/core/dom/container_node.cc
@@ -1394,7 +1394,7 @@
   DCHECK(change >= kUpdatePseudoElements || ChildNeedsStyleRecalc());
   DCHECK(!NeedsStyleRecalc());
 
-  for (Node* child = lastChild(); child; child = child->previousSibling()) {
+  for (Node* child = firstChild(); child; child = child->nextSibling()) {
     if (child->IsTextNode()) {
       ToText(child)->RecalcTextStyle(change);
     } else if (child->IsElementNode(


I don't think there's anything actionable here. It just shows how hard these perf results are to deal with :/ (i.e. Issue 866000)

Deleted: Screenshot from 2018-10-18 13-04-51.png 28.9 KB

	Screenshot from 2018-10-18 13-04-51.png 28.9 KB View Download

*Issue 894287 rather -- "rendering benchmark results is noisy"