Sigh, reloading the page and tracing again I can't get this to repro. When it did repro it happened every time though. I've seen this same super expensive VisibleUnits thing before which makes me think there's some bug with a race maybe?

The page you point:
https://elements.polymer-project.org/elements/iron-list?view=demo:demo/index.html&active=iron-list

shows a card(see attached image). Thus I couldn't find any scrolling and reproduce. 

I guess the issue is on a page of the six demos.
Elliott, could you explain more?

Deleted: キャプチャ.PNG 39.9 KB

	キャプチャ.PNG 39.9 KB View Download

There are two suspects:
1. FlatTreeTraversal::parent, child, nextSibling, previousSibling
2. Many calls of Document::updateStyleAndLayoutTreeIgnorePendingStylesheets()
 - When there are style sheet placeholder and pending HTML imports, USLIP() does layout for every call due by setNeedsStyleRecalc(SubtreeStyleChange, StyleChangeReasonForTracing::create(StyleChangeReason::CleanupPlaceholderStyles));

Suspects 2 can explain esprehn@'s experience in #c2.

There was nothing under that slice, and it was every frame. It wasn't a large style recalc or layout, it was the code inside VisibleUnits::canonicalPosition doing something expensive like walking the whole DOM or layout tree repeatedly. Of course I can't reproduce now, which makes me think this is a race condition. Once you get into the state where this happens every frame we pump has this at the start of it though.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot