Perf #307
Perf #307
Conversation
blasten
force-pushed
the
perf
branch
4 times, most recently
from
da016a4
to
8ed08cd
Compare
| Polymer.dom.flush(); | ||
| // Items should have been rendered prior scrolling to an index. | ||
| if (!this._itemsRendered) { |
There was a problem hiding this comment.
Remove _itemsRendered from the properties object.
|
@tgsergeant would you mind trying this out? |
|
Cool! This is a definite improvement. Here's a trace from chrome://history with this patch applied. It splits the stamping into 5 sections, with around 15-20fps. With devtools CPU throttling turned on, it correctly splits into more sections and maintains a similar frame rate. One thing to consider is that there can be an extra 10-20ms worth of work after the iron-list yields to update layers and paint and so on. This adds on to the 50ms allocated for stamping items, and means that frames can last longer than intended.
|
|
However, this change does seem to have caused the stamping of the first page to get slower. I'm not sure what is causing the difference. Old: New: |
|
@tgsergeant could you export and share with me the timeline data for both the old and new version? I think I might know why. |
|
@tgsergeant this commit should fix the issue. Would you mind giving it a try? Also, fyi: PolymerElements/paper-checkbox#149. You should be able to use |
|
👍, that looks more like it. Thanks! (and yes, we're eagerly awaiting |
|
so what's the status on this? it'd be really helpful for Chrome's history UI |
|
@danbeam I'm testing a few things and then it should be ready to merge. |
|
LGTM |
Ref: #301
Timeline for first paint
Current (waiting 16ms, job=as many nodes as they fit on the list's viewport):
After (waiting for requestIdleCallback, ~50ms job):
Conclusion:
Looking at frames for the offscreen items (the ones after the first frame on the screenshot), we can conclude that this PR does make the app more responsive by yielding control back to the main. It does that by keeping track of the cost of stamping a single template and then estimating how many instances of that template could be grouped into a block of ~50ms as recommended by RAIL
cc @justinfagnani