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

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


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

chromium-rel-mac11

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16cf456e040000

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

SetResource() in ResourceFetcher for FontResources
By japhet@chromium.org · Mon Dec 18 21:42:32 2017
chromium @ a1bfc9f9cb531a1d5dd1e28b51a38b728ece1235

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

I'm surprised that a1bfc9f caused such a large perf regression. I suspected the change of webfont intervention triggering condition, but it's unlikely since FirstPaint also regressed.

Reproduced locally, and took chrome:tracing with some additional categories.
Free_fr_2017-12-21_13-17-41_82125.html is from ToT (9db7eff9),
Free_fr_2017-12-21_13-22-08_13800.html is from ToT with a1bfc9f reverted.

In the ToT trace, in CrRendererMain around 6,000ms, there are a lot of DecodeFont calls inside StyleEngine::updateActiveStyleSheets.
It looks like same web fonts are decoded repeatedly (every time stylesheet gets updated?).

Deleted: Free_fr_2017-12-21_13-17-41_82125.html 4.4 MB

Free_fr_2017-12-21_13-17-41_82125.html 4.4 MB View Download

Deleted: Free_fr_2017-12-21_13-22-08_13800.html 4.4 MB

Free_fr_2017-12-21_13-22-08_13800.html 4.4 MB View Download

Ah, that is probably because FontResource::AllClientsAndObserversRemoved() is called.

When stylesheet gets changed, RemoteFontFaceSource can be discarded and re-created. Before a1bfc9f, FontResourceHelper is also a client of FontResource and is alive over stylesheet changes, keeping the FontResource's client list non-empty.

Nate, any ideas to fix this? Should we revive FontResourceHelper?

Restoring FontResourceHelper would work. Though I guess I should ask: is there a reason CSSFontFaceSrcValue can't just be a FontResourceClient? Is it important to keep CSSFontFaceSrcValue non-GCed or something?

CSSFontFaceSrcValue is a GCed class but uses non-virtual Trace(), so it cannot inherit FontResourceClient which is GarbageCollectedMixin? (not sure)

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

commit 3a87be14e46d7d1946da2277ba03751e96fe0e04
Author: Nate Chapin <japhet@chromium.org>
Date: Fri Jan 05 20:42:12 2018

Restore CSSFontFaceSrcValue::FontResourceHelper

This FontResourceClient keeps a longer-term client to a given
FontResource, ensuring that if other FontResourceClients add/remove
themselves, the FontResource::font_data_ doesn't get thrashed.

This is a partial revert of
https://crrev.com/a1bfc9f9cb531a1d5dd1e28b51a38b728ece1235

Bug:  796654 
Change-Id: I0a6a65835c9dd97a7e7d853ddef95aefd3299cfd
Reviewed-on: https://chromium-review.googlesource.com/848014
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527372}
[modify] https://crrev.com/3a87be14e46d7d1946da2277ba03751e96fe0e04/third_party/WebKit/Source/core/css/CSSFontFaceSrcValue.cpp
[modify] https://crrev.com/3a87be14e46d7d1946da2277ba03751e96fe0e04/third_party/WebKit/Source/core/css/CSSFontFaceSrcValue.h

Looks like the partial revert did the trick.

 Issue 797116  has been merged into this issue.