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 attaching property to template in event #1997

Closed
frozeman opened this Issue Apr 1, 2014 · 4 comments

Comments

Projects
None yet
5 participants
@frozeman

frozeman commented Apr 1, 2014

Hi @avital,

i revisited the memory test i did a while ago while searching for leaks i'm seeing still in my app.
I discovered if one add a property with a very large string to the template instance in the rendered callback, it gets cleaned up properly. If you do the same in the event it won't.
Please see the https://github.com/frozeman/MeteorMemoryTest repos latest commit.

If you uncomment line 28 in the testProject.js you will find that the large array add in the event will grow the memory.

Shouldn't the template instance passed into the event get cleared up properly as well?

@glasser glasser added the Blaze label Apr 4, 2014

@avital

This comment has been minimized.

Contributor

avital commented Apr 10, 2014

Hi @frozeman, thanks for keeping us on our toes with memory leaks :)

I've confirmed this issue, and it comes down to event handlers not being cleaned up when a component is destroyed (see a comment in domrange.js: XXX clean up events in $_uievents. Event handlers keep a reference to this (the template instance) which is why we see this behavior.

I'm happy you found a workaround in the meanwhile. We should fix this, but since @dgreensp is rehauling the Blaze component API and DOM range-tracking mechanism it's best to wait until that's done to see if it's been resolved or not.

@avital avital added the confirmed label Apr 10, 2014

@frozeman

This comment has been minimized.

frozeman commented Apr 15, 2014

ok thanks.
i don't want to be annoying here :)

But i guess in the future when more and more goes towards single page apps we will see memory management becoming a bigger issue.

You can check out the beta of our app here http://beta.tunedin.de. The memory is kind of stable (except for that image slider on the featured page), but its a lot ± 100mb.

Sorry german is hardcoded for now you can help yourself by typing Helpers.setLanguage('en') into the console.

@dmhood

This comment has been minimized.

dmhood commented May 7, 2014

@avital Is there any progress or a workaround for this issue? I have a kanban board I'm building in meteor, and when switching between boards (similar to the TODO list example) with ~100 tasks, my memory usage rockets up. If I quickly click between two boards I can get the memory footprint well over 200mb in a few minutes.

As with @frozemanm I've narrowed this down to so many templates being created/destroyed.

@estark37

This comment has been minimized.

Contributor

estark37 commented May 15, 2014

Hi @frozeman -- we think we fixed this in b46edf3, and the attached screenshot shows the memory profile of your repro before and after the fix. Thanks!
screen shot 2014-05-15 at 2 16 23 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment