Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak when drawing progress #221

Open
Blackvals opened this issue Jun 14, 2021 · 2 comments
Open

Memory leak when drawing progress #221

Blackvals opened this issue Jun 14, 2021 · 2 comments

Comments

@Blackvals
Copy link

Hi,
We are using this component at version 3.0.1 on our application with angular 8 and I have been investigating a memory leak narrowing it down to this component. Let me give some context on how we use this component.

  • We have an always-visible part with the round progress and use it to show the progress of the current operation taking place.

  • Those operations can range from minutes to hours.

  • We set a timer (using setInterval and clearInterval at the end, also tried with rxjs timer) of that every 1 second updates that current progress that is fed to this component.

  • Component is configured as follows:
    <round-progress class="c-round-progress__circle" [current]="current" [max]="max" [color]="color" [stroke]="stroke" [background]="background" [radius]="40" [semicircle]="false" [rounded]="false" [clockwise]="true" [responsive]="true" [duration]="1000" [animation]="'easeInOutQuart'" [animationDelay]="0"></round-progress>
    Stroke is 1, Max and Current change depending on the operation, and I don't think colors are relevant to the problem.

So, with the UI on idle state from a user perspective but the round-progress being updated, I could see memory increasing (even considering garbage collection after some time). Reproducing the same scenario but removing your component from the screen makes memory stable.
I tried also with the demo application in latest version (6.0.1) and after toying around for some time I could see that memory went up (checking chrome task manager). Even in one case on the demo app I found memory going crazy up without me bothering it anymore, to later be cut down by the GC (I assume; this rare situation could be just Chrome though).
I have briefly looked at your code but I have not seen a clear reason behind it, though I'm no JS/TS expert.

Could it be a configuration problem? It is a problem to have matching duration and timer updates? What happens if animation hasn't finished and a new change occurs?

@crisbeto
Copy link
Owner

Honestly there isn't that much that could cause a memory leak in the component since it's basically taking the values of a bunch of inputs and generating an SVG out of them. The one place that is slightly risky is the animation based on requestAnimationFrame, but if that were leaking, you'd see a spike in CPU usage, rather than a memory leak (see https://github.com/crisbeto/angular-svg-round-progressbar/blob/master/src/lib/round-progress/round-progress.component.ts#L109). There is also some logic that should prevent overlapping animations.

One thing to try is to update to the latest, or at least a later, version of Angular which may contain a fix for your leak.

@Blackvals
Copy link
Author

Thanks for your quick response.
I agree with you, the only part on your code that brought me doubts was the requestAnimationFrame precisely for being a recursive call based on the duration. As for the CPU spike, I was not checking it because the main resource problem was memory related, but it could be.

Following that trail, I have tried reducing the duration to the minimum (1) and the memoy stays in check. In the end, if we are updating the progress every second for a operation in the range of minutes or hours, it is barely noticeable the fancy animation; so is a trade-off we can pay.

Unfortunately the Angular update is something not possible at the moment, but something we look forward for the near future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants