angular-ui / ui-ace

This directive allows you to add ACE editor elements.
http://angular-ui.github.io/ui-ace
MIT License
578 stars 172 forks source link

memory leaks #22

Open amitport opened 10 years ago

amitport commented 10 years ago

Ace will leak when the directive is removed by angular.

I had the editor in a tab-content controlled by ng-switch, the results were bad.

My solution for now is just using my own tab implementation that does not delete and recreate the elements like ng-switch does.

ricochet1k commented 10 years ago

I think this is happening because the editor is never destroyed. I haven't done a lot of testing, but this should fix it:

    scope.$on('$destroy', function() {
      acee.destroy();
    })
douglasduteil commented 10 years ago

So true. No need PR I'm adding it right now...

amitport commented 10 years ago

I'm still getting a small memory leak with acee.destroy. I think this is due to https://github.com/ajaxorg/ace/issues/344. So I'm still not using ui-ace in destroy-able context, but thanks for fixing things on your end

douglasduteil commented 10 years ago

Yeah me too here

ricochet1k commented 10 years ago

@douglasduteil So I did a bit of testing with the Firefox debug build (29.0a1 (2013-12-12)) I'm been using. The testing procedure I followed is: Create a new profile. Paste your plunkr into the start tab. Open about:memory in a new window. Minimize memory and then Measure and Save... producing this file

Then click on the create/destroy button 1000 times using xdotool, which should result in the editor being created and then destroyed 500 times. I then clicked the Minimize memory usage button and Measure and Save... again, producing this file

Then click on the create/destroy button 2000 more times using xdotool. I then clicked the Minimize memory usage button and Measure and Save... again, producing this file

Using Firefox's about:memory Load and Diff button, I was not able to find any noteworthy difference between file 2 and file 3.

Edit: I was not able to get the same kind of dump from Chrome, but I did the same kind of rapid clicking test with xdotool using the latest unstable of Chrome and I did not notice a memory leak. I even tested creating and deleting about 12 editors all at once to speed it up. The memory used seems to relate more to the total number of editors open at one time, not the number of times they were created and destroyed. After the clicking stopped, I left the tab and the Task Manager open, and the memory usage slowly dropped back to the same point the test with only one editor open had, at around 150M Private Memory, 54M (26M live) JavaScript memory.

douglasduteil commented 10 years ago

@ricochet1k :+1: that's some very precision data there ! Thanks :) So the latest Firefox (>= 29.x) and Chrome (>= 31.x) can handle it ? Do you know a way to track all this like webpagetest or something ?

ricochet1k commented 10 years ago

Browsers don't typically offer heap size data to the running website, so something like that is going to be hard to make. It would probably have to involve a plugin/extension of some kind. I haven't been able to find any that do it.