How to start debugging slow Polymer perf?

al...@streak.com

未读，

2015年7月24日 16:33:012015/7/24

收件人 Polymer

I'm writing a Polymer based app and at some point the UI has gotten really slow to render and really slow to scroll.

Does anyone know of any resources or tips on the best way to get started debugging polymer performance issues?

Eric Bidelman

未读，

2015年7月24日 17:20:302015/7/24

收件人 al...@streak.com、Polymer

As with any web app, the Devtools Timeline is your best friend when it comes to anything related to jank (rendering, scrolling, paint issues): https://developer.chrome.com/devtools/docs/timeline

The usual suspects are large paints on scrolling or doing extra work (layout, etc). Be sure to turn on "Show paint" rects to see where your time is being spent: https://developer.chrome.com/devtools/docs/rendering-settings

There's also a ton of great content at http://jankfree.org/ to learn more.

On Fri, Jul 24, 2015 at 3:33 PM <al...@streak.com> wrote:

I'm writing a Polymer based app and at some point the UI has gotten really slow to render and really slow to scroll.

Does anyone know of any resources or tips on the best way to get started debugging polymer performance issues?

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/74af7c92-213c-4bf1-b3fd-30e3f895ee1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Aleem Mawani

未读，

2015年7月24日 17:22:502015/7/24

收件人 Eric Bidelman、Polymer

Thanks for those.

Are there any polymer specific perf issues we should be aware of with respect to data binding or templating? If there are perf issues in this area, would they be relatively easy to spot in the devtools?

Eric Bidelman

未读，

2015年7月24日 17:30:512015/7/24

收件人 Aleem Mawani、Polymer

Scrolling issues usually means poort interactions with css selectors and style recalcs are causing large paints. That would be my guess. That doesn't have to do with templating or data binding but it's hard to say without seeing your app or knowing more about the code.

Another thing to try is use <template is="dom-if"> to only stamp initial DOM that you need. I've seen people create apps with 5000-7000 DOM nodes on page load. There's never a good idea for any app.

Aleem Mawani

未读，

2015年7月24日 18:10:492015/7/24

收件人 Eric Bidelman、Polymer

Thanks for the clue - looking at the dev tools, you're correct that the bad scrolling perf is coming from excessive paints. Turning on "show paint rectangles" I was able to narrow it down to the paper-drawer-panel's main content that was creating the issue. Here is a mimal example that shows that the main content pain will repaint its entire contents during scrolling. Seems like an issue with the paper-drawer-panel?

<!DOCTYPE html>

<html>

<head>

<style>

.maincontent {

background: #cf9a9a;

overflow: auto;

}

.sidebar {

background: white;

}

</style>

</head>

<body>

<paper-drawer-panel>

</div>

</div>

</paper-drawer-panel>

</body>

</html>

If you load that you'll see that the maincontent div will always repaint in its entirety.

Frankie Fu

未读，

2015年7月24日 20:09:322015/7/24

收件人 Aleem Mawani、Eric Bidelman、Polymer

I tried your minimal example and when I scrolled the content I didn't see the repaint on the entire content that you mentioned. I was testing the latest paper-drawer-panel on Chrome 44.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CADBYpym5hR8p3oKuxEj3Zb_RuGTQ7i4GksNjKkvhGCi-kBXaGg%40mail.gmail.com.

al...@streak.com

未读，

2015年7月24日 21:21:042015/7/24

收件人 Polymer、ebi...@gmail.com、f...@google.com

Hmmm. Attached video showing repaints. and screenshot of me being on chrome 44

repaint.mov

Screenshot 2015-07-24 18.20.02.png

Eric Bidelman

未读，

2015年7月25日 10:21:092015/7/25

收件人 al...@streak.com、Polymer、f...@google.com

Are you on a retina machine? If not what kind? If you're on a Mac that's likely the difference. Chrome has a different rendering path on retina vs. non-retina screens.

Aleem Mawani

未读，

2015年7月25日 10:21:572015/7/25

收件人 Eric Bidelman、Polymer、f...@google.com

Non-retina macbook air 13"

al...@streak.com

未读，

2015年7月27日 12:09:332015/7/27

收件人 Polymer、ebi...@gmail.com、f...@google.com、al...@streak.com

So all sites that use polymer drawers will have slow scroll perf because the main content section always repaints?

Emmanuel Garcia

未读，

2015年7月27日 15:11:132015/7/27

收件人 Polymer、ebi...@gmail.com、f...@google.com、al...@streak.com

I have confirmed this issue. It seems like a regression in chrome that can be reproduced in a non-retina display screen by just adding overflow: auto. Here's an example: http://jsbin.com/midoga/edit?html,output . I will keep you posted as we find out more.

Aleem Mawani

未读，

2015年7月27日 15:23:152015/7/27

收件人 Emmanuel Garcia、Polymer、ebi...@gmail.com、f...@google.com

Thanks for looking into that.

Emmanuel Garcia

未读，

2015年7月27日 19:21:302015/7/27

收件人 Polymer、ebi...@gmail.com、f...@google.com、al...@streak.com

I opened an issue in Chrome. (It should be public soon https://code.google.com/p/chromium/issues/detail?id=514303)

tl;dr

It's not an issue in Chrome, indeed, Chrome doesn't do composited overflow scrolling traditionally for non-retina outputs because those outputs need LCD text. That's why you see that large paint rectangle. After talking to some folks, the paint might not be as bad as it looks like since some of those are optimized. I'd say that we should pay attention to the FPS meter as it gives a better picture of how many frames per second we ship. Your drawer-panel example runs at nearly 60fps even though we get that big paint region.

Thanks

fps.png

Aleem Mawani

未读，

2015年7月27日 21:10:162015/7/27

收件人 Emmanuel Garcia、Polymer、ebi...@gmail.com、f...@google.com

Thanks for following up.

Aside from the toy example, if we have a lot of content in the contents section of the drawer, this could get very expensive right (if it need to repaint every single child of the contents div)? Imagine static content pages that are very long.

I guess this is where using the iron-list would help, but it seems strange that there would be bad perf issues on rendering static content.

回复全部

回复作者