Repeated Custom Elements do not release memory

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.

demo here See file src/display.js

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.

1 Like

Your demo does detach for me in both Chrome and Safari.

1 Like

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.

1 Like

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>

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:

  1. See idle consumption of codesandbox subframe ~119,000K
  2. 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.
  3. 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?
  4. Add another 10,000 items. Allow to settle. See idle consumption ~234,000K. Nope, the theory about element reuse is out the window.
  5. 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.

Any ideas?

1 Like

I think I recognize the leak, it’s been fixed here

we will need to ping @EisenbergEffect for a release.

Thanks for notifying about this.

Awesome thanks @bigopon!

@EisenbergEffect is this next release of aurelia-templating, to include PR 678, major or minor (semver)?

@mcorven It has already been released. It’s only our official release notes blog post that is a bit behind. That is scheduled for this week.

1 Like

@EisenbergEffect oops, sorry for that, thanks for the note.

@mcorven the sandbox example was using aurelia-templating@1.10.1, I updated it to 1.10.3 and it’s fixed now.

Can you try update aurelia-templating to 1.10.3 and try again?

@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:


1 Like

here is my test:

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

@bigopon When I run this in a tab of its own, I’m seeing an initial heap size of 7.5MB - 8MB rather than your 27.7MB.


1 Like

did you run it with templating 1.10.3? And im not sure why the difference

Yes I was sure to update the sandbox to 1.10.3. The good news is that the exponential consumption has resolved with 1.10.3.


Glad to hear that. Because i cant replicate the leak on my side :sweat:

1 Like