If I bind an array to a repeated custom element, the attached() is called for each instance of the custom element. But when I clear the array (using myArray.splice(0) as suggested elsewhere), the custom element instances do not call detached. Additionally, by repeatedly adding items to the array and clearing them, I see that my memory consumption steadily increases.
In my real-world implementation, the custom element instances each subscribe to EventAggregator - and because detached() isn’t called, I’m unable to clean up.
Thanks @huochunpeng, I missed the fact that the sandbox console wasn’t scrolling to the bottom as output arrived. Unfortunately I do have this problem in the production code - I suppose getting the sandbox to exhibit the same issue will be my best way of finding the root cause.
Thanks for looking in any case - I’ll post back again if I draw another blank.
Okay @huochunpeng, I’ve revised the demo to fully-reproduce the issue I’m seeing in production. From some background, in our code we use a set of custom elements for our “dropdown” like this:
<cc-dropdown placeholder="Demo" value.bind="selectedValue">
<cc-dropdown-item repeat.for="item of arrayOfItems" value.bind="item.value">${item.displayText}</io-dropdown-item>
</cc-dropdown>
In the View for <cc-dropdown> we use a slot to place the repeated <cc-dropdown-item> instances.
With the codesandbox updated, you can open Chrome’s Task Manager and reproduce as follows:
See idle consumption of codesandbox subframe ~119,000K
Add 10,000 items. I know it’s crazy - just humor me, it makes the memory consumption abundantly noticeable. Allow 10-15 seconds to settle. See idle consumption ~185,000K.
Click “Clear Array” button. Allow to settle. See idle consumption still ~185,000K or even a bit higher. WTH?? Maybe Aurelia is holding onto those DOM elements in-memory for reuse to speed up the next UI update?
Add another 10,000 items. Allow to settle. See idle consumption ~234,000K. Nope, the theory about element reuse is out the window.
Click “Clear Array” button. Allow to settle. See idle consumption still ~234,000K.
I started to wonder if the use of a slot in <cc-dropdown> has anything to do with it, so I created a second codesandbox with a simple use of <ul> and <li>. With the same steps above, repeatedly adding 10,000 items and then clearing, I see the “cleared” memory consumption rising although at a much slower rate than with the 1st sandbox.
Disregarding the statement earlier about detached() not getting called (which was a brainless tangent on my part), I’m now back to the heart of the issue - what appears to be a memory leak. Our users reported the application was coming to a crawl, and the browser tab crashing, when using a specific dropdown in the app several times. We found that the dropdown was being populated with WAY TOO MANY items - but even with the number of array items reduced to a more reasonable level, we’re still seeing memory consumption rise over the course of the user’s session.
@bigopon With 1.10.3 installed in both the sandbox and my own app, the situation is consistently improved. I’m still not seeing all the RAM released though. Below is a log of actions against the sandbox (with 1.10.3 installed) while monitoring the consumption using Chrome’s Task Manager on the sandbox’s iframe. FYI after each action I waited 10-15 seconds for things to settle down:
Snapshot timing:
1: initial
2: after added 2000 items
3: after clear all items
4: after added 10000 items
5: after clean all items
6: after doing nothing after (5)
I think you need to open the app in a separate window to test, instead of testing it in a sandboxed tab. The button to open the site is on the right, as you can see here