Memory garbage collection

[ahedderich]

While developing today i noticed that my Polymer powered page had an enormous hunger for memory after manually refreshing the tab several times.
I noticed the same behavior on https://www.polymer-project.org/summit (and all Poylmer sites i tested for that matter)
Both in vanilla Firefox and Chrome, after a few reloads, memory usage already exceeds 200Mb with open end, depending of the reload count. I pushed it over 500Mb and after 15 minutes idle tab, it didn't show any sign of reduction.
Same test with GitHub frontpage: While memory usage increases after a few moments the GC kicked in and reduced a lot.

Is there a special reason why this happens?

[ebidel]

The summit sites embed the YouTube player, which tends to each memory and take up CPU cycles. Even if you're not viewing the homepage, the iframe is created an exists on the page. FWIW, I just brought up the site and did a couple of refreshes. The memory went up (expected) but the GC also kicked in after a few seconds.

If you have the devtools open when testing, this can also eat a LOT of memory. The more you refresh, the slow the page gets. At least, that's been my experience. Having DevTools open while testing is also known to low a page down :(

What sites have you been testing? I did another test on https://www.chromestatus.com/features (which is Polymer 1.0) and did see memory go up ~20mb/page reload but then got GC'd right after.

[leogr]

I noticed the same behaviour. I made some tests using the latest version of Chrome both on Mac and Linux, with DevTools closed and observing the memory from Chrome's taskmanager

With https://elements.polymer-project.org, just reloading the page about 100 times the memory grows up to 1 GB (JS Memory ~650Mb live). Leaving the page opened for hours didn't show any sign of reduction.

Same issue with https://www.chromestatus.com/features and another polymer powered site I'm working on. I noticed this strange behaviour since two weeks while, maybe after the 1.1.x release (but I'm not sure about that and I didn't test with 1.0.x).
While developing it's very frustrating cause the tab crashes dozen of time a day :)

[ahedderich]

On https://www.chromestatus.com/features
First request:

After a few more and navigation via top navigation:

Although the memory usage doesn't increase that much, the number of nodes starts on every new request with nearly its max value. This effect can also be observed while switching pages between "Features" and the "Metrics" pages on https://www.chromestatus.com/features
With a regular webpage like the google.com front page the count count keeps almost the same per reload.

If paper elements are used outside of a fully Polymer based environment, like in a wordpress theme for styling, the effect can also be observed while browsing the pages which amount to a significant memory usage.

[ahedderich]

After a lot of testing, it seems the issue is related to certain elements only. If an paper-input element is attached to the dom for example.

[arthurevans]

This appears to reproduce in Firefox as well (measuring using about:memory), so I'm thinking Polymer. I've tried running the catalog with Polymer with versions back to 1.0.5 and the behavior appears the same. (I didn't try changing the polyfills or anything else, so there's always the possibility the issue is somewhere else).

[ebidel]

I'm afraid #2452 (comment) isn't a good test. The "Features" and "Metrics" pages are completely separate pages, with different resources, DOM elements, and even page structure. I'd expect the JS heap and Nodes to go way up navigating between the pages and keeping the timeline open. It's not a SPA. Namely, the metrics page also has lot of DOM nodes and custom elements.

However, refreshing https://www.chromestatus.com/features a few times, this is what I see in Chrome:

[leogr]

Gmail VS. https://www.chromestatus.com/features
(refreshing 5 times)

Note: I used Gmail just as example of a non-Polymer powered site.

[xharaken]

Maybe is this related to https://code.google.com/p/chromium/issues/detail?id=529941?

If you're using a CustomEvent, the bug may be related.

[MartinMoizard]

@azakus Thanks, after a few tests, commit 76a5f17 seems to fix the issue.

[ahedderich]

Yup. 76a5f17 works in my test cases.

[addyosmani]

76a5f17 appears to address the issues noted here fine. Thanks @azakus!