Memory leaks while load new forms

[asednev]

I discovered that Schema Form leaks memory. This might be similar to #200. Easiest way to reproduce the problem is to open demo.

1. Go and open every single example available in drop down list. This should have loaded all possible templates and cached them.
2. Capture heap size (20.4 Mb for me in Google Chrome)
3. Repeat steps 1 & 2, notice heap size continues to grow 22.4 Mb, 24.9 Mb, 27 Mb, 29.1 Mb, and so on.

If you examine individual heap snapshots, it's evident that memory retained by "Detached DOM Tree" and number of objects keeps growing. Something is holding on to DOM Nodes. In a bigger application this starts causing problems real fast. I will appreciate any help in isolating and fixing this issue.

[asednev]

I have an update. I narrowed down this issue to "Kitchen Sink" example. If I play with all other examples without ever opening "Kitchen Sink", there are no memory leaks.

[asednev]

Here's more on this issue now with Firefox. I will really appreciate any help on getting to the bottom of this issue.

Open demo site http://schemaform.io/examples/bootstrap-example.html. Select example "Array".

Interact with form by entering name & email, observe that checkbox "Yes, I want spam" appears once valid email was entered. Interact with checkbox. Now, change example to "Simple" (so that checkbox is removed from DOM). Open a new tab with about:ccdump. Run CC Analysis. Filter by "checkbox". We now have 1 orphaned DOM element related to checkbox (specifically div that wraps checkbox, this is just to reduce the noise from all other orphan elements):

Go back to example "Array" and interact with form some more. I will add 3 entries by clicking "New" button.

Switch back to "Simple" example. After re-running ccdump, we can now see 4 orphan elements (1 earlier + 3 added recently)

More interaction results in more orphan elements. Amount of memory retained by orphan dom elements only keeps growing:

[davidlgj]

Hi @asednev, nice work! The first thing that springs into mind is if it's connected to the condition that is on the checkbox (the kitchen sink also has a condition). It's implemented by slapping on a ng-if on top elements of the template. In this case the orphaned DOM node. Here is the code: https://github.com/Textalk/angular-schema-form/blob/development/src/services/decorators.js#L198

It could be that it's a leak in Angulars ng-if angular/angular.js#11618

[davidlgj]

Might not be the ng-if after all. I reproduced your steps @asednev, and got an orphan element with ccdump. And then I modified the code, just commenting out the if at line 198 so that the ng-if never gets added. But I still got a orphan checkbox in ccdump...

[davidlgj]

...there are a lot of other ng-ifs in the templates though. So it's still worth investigating.

[davidlgj]

@asednev I think i have it! Or at least something. I might have found two leaks. In both cases I don't know why it leaks though.

Ok, so to test I use Firefox and ccdump. I load the examples/bootstrap-examples.html, open a new tab with about:ccdump. Click on Run CC Analysis and search for "orphan". No result. Then I go back change example to "Basic JSON Schema Type" and then back to "Simple" (no need to interact with the form). Then I click on Run CC Analysis again (it remembers the search for "orphan"). And Boom, several orphan DOM nodes that I recognize from the form.

Using this as a test I started reducing it down and down and finally I had it just adding and removing a single DOM node. Not doing a $compile or anything Angularish.

So I found if I change two things I no longer get any orphan nodes! (hurray!)

The first thing is to remove the slots functionality by setting the slots argument to undefined.
https://github.com/Textalk/angular-schema-form/blob/development/src/services/builder.js#L259
So

}, slots, undefined, undefined, lookup);

becomes

}, undefined, undefined, undefined, lookup);

Also https://github.com/Textalk/angular-schema-form/blob/development/src/services/builder.js#L167
needs to be changed so it doesn't crash:
js if (slots && form.key) {
I'm guessing that the slots object keeps is captured by a closure and for some reason keeps stuff around. But that's just a guess. Slots is a not so used functionality so you can probably
live without it.

The second thing is stranger. btw this doesn't apply to the new builder and the new bootstrap decorator. Anyways, I found that if I changed the name of the directive bootstrap-decorator to just bootstrap I no longer get any orphans. Actually any name with - creates a leak and any name without - is fine!

To change the name of the decorator just edit: https://github.com/Textalk/angular-schema-form/blob/development/src/directives/decorators/bootstrap/bootstrap-decorator.js#L4

The template tabs.html directly uses bootstrap-decorator tags and must be changed as well.
In my reduced testcase where I did no $compile so no directive was ever found or linked changing the name of the element to something without dash still made a difference. I'm flabbergasted by this.

Please try it yourself and see if it helps!

[davidlgj]

Urgh.. I'm not getting any consistent results :) Still getting leaks when trying out the array example. I also changed any reference to sf-decorator to sfdecorator (and sfDecorator to sfdecorator)

Sometimes it seems to leak, sometimes it doesn't.

[davidlgj]

I hopped over to chrome to see if I get the same results and some good news.

This is a timeline recording with me changing the example form on http://schemaform.io/examples/bootstrap-example.html, ending at "simple" and then finishing of with a forced GC.

Look at all those DOM nodes!

The same thing, but with my locally modified version (no slots, just "bootstrap" and "sfdecorator").

Ahhh... that's better :) Maybe not perfect, but much much better.

[davidlgj]

Oh no. I might have jumped the gun just now. I can't seem to get the leak back, even if I revert back to the unpatched code (development branch). I only get the leak at http://schemaform.io/examples/bootstrap-example.html now. (When measuring with the timeline in chrome as per last post). Soo back to square one :)

[asednev]

@davidlgj I have seen similar behavior when locally it will stop leaking. But than the problem re-surfaces. That was in Chrome. In Firefox, it leaks consistently.

[davidlgj]

@asednev memory leaks are hard! Anyway. I got to get a small release out and then start transitioning to the new builder. If you can please try the things I did and test if it makes any difference.

[asednev]

Thank you @davidlgj. I yet to try the things that you discovered but I will keep you posted.

[upq]

Any news here?