Components: datepicker memory leak

Created on 7 Dec 2019  路  15Comments  路  Source: angular/components

Reproduction

Steps to reproduce:

  1. go to https://material.angular.io/components/datepicker/examples
  2. open datepicker and close multiple times
  3. each open and close action generate 135KB memory leak.

The more times we open and close datepicker, the more memory are allocated.
Garbage collector does not clear all allocated memory.

Expected Behavior

datepicker without memory leaks

Actual Behavior

memory leaks

Environment

  • Angular: 8.2.14, 9.0.0-rc.5
  • CDK/Material: 8.2.3, 9.0.0-rc.5
  • Browser(s): Chrome 78.0.3904.108
  • Operating System: Fedora 31
P2 animation has pr perf

Most helpful comment

@angular/material 9.1.0solve memory leak in datepicker component

All 15 comments

related issue: https://github.com/angular/angular/issues/25744

it looks like the biggest leak comes from @angular/animations module
after remove matDatepickerAnimations and rest of "animations" code from datepicker
each open and close action generate only 1.3KB of memory leak.

The animations leak is fixed by https://github.com/angular/angular/pull/34409.

Closing since this was caused by the framework and because the fix has been merged there.

it's look like the memory leak still exists.
I built and launched dev-app from 9.0.0-rc.6 tag.
inside DOM the dev-app element has attibute ng-version="9.0.0-rc.7"
Also inside animations-browser.umd.js i see changes from fix https://github.com/angular/angular/pull/34409.
So theoretically fix should work, but still each open and close action generate 130KB memory leak.

I can see the memory leak as well so the root cause probably wasn't angular/angular#34409. I spent some more time looking into it and I'm not sure exactly why it's happening, but here are some observations:

  1. It only happens for datepickers in popup mode. There's still a smaller leak in dialog mode, but it only ends up leaking one datepicker worth of elements and it doesn't stack up like the current leak.
  2. It seems to happen, because in popup mode we detach the overlay and we only dispose of it on destroy, but by that time the elements have leaked out already. If I switch to disposing it on every close, it starts behaving like dialog mode, but this isn't ideal because it breaks the closing animation.
  3. The leak seems to be due to the fact that we remove the DOM nodes once the animation has finished here. If I switch it to remove the element immediately, it stops leaking. This is confusing, because I can verify that the callback always fires at the proper time and the elements do get cleaned up. There might be something further down the line that expects the elements to have been removed immediately.

bad news: memory leak is a little bit smaller (120KB instead 130KB) but still exists.
I built and launched dev-app from 9.0.0-rc.8 tag.
Devtools Source panel, inside /src/material/datepicker/datepicker.js i see changes from angular/components#18102.

But still each open and close action generate ~120KB memory leak.

The 40x leak is what I was referring to above when I said "There's still a smaller leak in dialog mode", but do you see the HTMLTableCell count increase if you keep opening and closing it? That's the part that my fix addressed.

even if the leak comes from the dialog, calling it "small" is a lot of abuse.
This issue should be closed after the leak has been repaired.

It's not small, but it's smaller since it doesn't leak for every open. I haven't been able to track down exactly where the other leak comes from, but it looks like it could be from the framework.

it looks like it's getting worse with every version of angular and components.

Angular 7.1.4
Components 7.3.7
Leak: 11.8 KB

Angular 8.2.10
Components 8.2.3
Leak: 59.5 KB

Angular 9.0.0-rc.13
Components 9.0.0-rc.9
Leak: 122 KB

I would also suspect something in the framework, since we haven't made any major changes to overlays or datepicker lately.

[email protected] provides significant improvement in memory profile

@angular/material 9.1.0solve memory leak in datepicker component

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_This action has been performed automatically by a bot._

Was this page helpful?
0 / 5 - 0 ratings

Related issues

xtianus79 picture xtianus79  路  3Comments

vitaly-t picture vitaly-t  路  3Comments

LoganDupont picture LoganDupont  路  3Comments

MurhafSousli picture MurhafSousli  路  3Comments

dzrust picture dzrust  路  3Comments