[OPEN] [#10] Memory leaks‎

Hi again,

Could you finally test this issue with ExtJS 5?

Could this problem be tested with current Ext.NET 3 version? or should it be tested directly with ExtJS 5?

Thanks again for your king support.

Quote:

---

Could you finally test this issue with ExtJS 5?

---

No. I wait Ext.NET v3.

Quote:

---

Could this problem be tested with current Ext.NET 3 version?

---

Yes, it could be, but Ext.NET v3 is not ready yet.

Quote:

---

or should it be tested directly with ExtJS 5?

---

If the problem is reproducible with Ext.NET v3, I will test with the raw ExtJS 5.

It appears the issue is still reproducible with ExtJS 5 and, therefore, in Ext.NET v3.

I've posted an update in the Sencha forum thread.
http://www.sencha.com/forum/showthre...=1#post1070368

Thanks @Daniil,

We have tested it directly with ExtJS 5 and it looks like we get better results than with ExtJS 4.2. Anyway, it still remains a residual memory leak for every iframe.

At this point, we will consider all our alternatives in order to upgrade our application to a newer versi?n.


Thanks again for your kind support.

Just reading your post on the Sencha forum, Daniil.

There's a lot of silence and many others voicing concern about the issue (and about the silence!)

I wonder, is it worth creating a separate ticket just for 5.x part of their forum? Maybe they will look at those ones more urgently?

Thank you for the suggestion.

Quote:

---

Maybe they will look at those ones more urgently?

---

I would bet they won't:)

We (Ext.NET) are probably not going to re-report it again for ExtJS 5. Though, you are totally free to do that if you want. Maybe, it will produce some effect indeed.

Currently, I have something to add on this topic. I tested it with a big, but fake JavaScript file and noticed pretty much the same (or comparable, at least) results as it is with the original ExtJS files. Here is a small retrospective story.

We deal with that iframes memory leaking problem quite a long time. I and others always had issues with testing and reproducing that problem. Often (or just always) the testing results depended on the version of browser and/or OS. Someone had some results in IE9 on his machine, but other person had very different results in IE9 on his machine. The same situation with Chrome and FireFox. And, also, with exact OS version.

Personally, I tested it a lot and I often had different results. For example, I initially tested with some browser and reproduced a big memory leak. Then I tested it in a few months and noticed that the situation improved a lot. Sometimes I even could not reproduce memory leaking at all and was happy that the problem is gone:) Until a next person reported the problem again that led me to retest and reproduce it again. Sure, it is quite easy to realize that the conditions of each testing cycle are always changed - the browsers and OS get their updates. It led me to think that it is very probable that ExtJS is not so a culprit of the problem and, maybe, browsers, their GC and, maybe, even OS are the main culprit.

Recently, I gave that problem another chance and tested, tested, tested. With all ExtJS - 3, 4 and 5. I don't remember that anyone has reported that problem with Ext.NET v1 (i.e. ExtJS 3), but I tried to test and saw that it is also reproducible with ExtJS 3, but in a much less extent than it is with ExtJS 4.

I asked myself what could be the difference between ExtJS 3 and 4 that leads that degradation? I thought like "Hmm, ExtJS 4 JavaScript and CSS are much bigger than ExtJS 4 and 5. Maybe, I should think about it more". It results in a thought to test it with some big JavaScript file, but a fake file. I generated a .js file like this:

Code:

---

var someNamespace = {};
SomeNamespace.someLongNameJustToIncreaseSpace0 = function() { var a, b, c, d; }
SomeNamespace.someLongNameJustToIncreaseSpace1 = function() { var a, b, c, d; }
SomeNamespace.someLongNameJustToIncreaseSpace2 = function() { var a, b, c, d; }
...
SomeNamespace.someLongNameJustToIncreaseSpaceN = function() { var a, b, c, d; }

---

Up to ~5 MB, for example.

While testing I noticed that I see pretty much the same (or comparable, at least) results that I see with the original ExtJS files. Also, the bigger file, the bigger memory consumption.

Yes, it still looks like ExtJS files consumes more memory. But it might be because of his complexity. At least, partially. I would assume if make a fake file more complex, then it might result in a bigger memory consumption.

Yes, it doesn't prove for 100% that there is no memory leaking in the ExtJS or Ext.NET JavaScript. I would still assume there is some. But now I am quite confident that the main (or, at least, one of the main) problem is the size of the ExtJS and Ext.NET files and the fact that the browsers' Garbage Collecting is not ideal with iframes and big JavaScript files.

How could we decrease the size of ExtJS or Ext.NET files? I would say nohow.

How could we improve the situation with browsers? Well, we probably should try to report it to Microsoft, Mozilla and Google and hope we will agree and do something. If somebody reports it to them, we would appreciate a lot. Maybe, we will report by our own at some point.

I should also note that with the current cycle of testing I didn't deal with FireFox, because I see memory problems in the last versions. With the last updates (it started a month ago or so) then I just serf the Internet via FireFox, I might finally notice that my system slows down and there is something like 1 or 1.5 GB of memory consumed by the FireFox process in the Task Manager. So, this time I tested with IE10 and Chrome only. On Windows 7 64 bit with all the updates.

Finally, I want to share a test case. Maybe, somebody wants to give it a try a well.

I usually ran a test during 5-10 minutes or so. I also tried to leave it for ~1 hour or so and, by the way, I have not been able to reproduce a "shutting down" memory leaking. I mean the browsers never hung up, because the memory consumption never didn't grow extremely. I would say it was always appropriate for me.

Parent

Code:

---

<!DOCTYPE html>
<html>
<head>
    <title>Memory leaks</title>

    <script>
        var counter = 0,
            iframe;

        var createIFrame = function (index) {
            var url = 'Child_fake_big_file.htm?index=' + index,
                iframe = document.createElement("iframe");

            document.body.appendChild(iframe);
            iframe.src = url;

            return iframe;
        };

        var startTask = function() {
            iframe[iframe.remove ? "remove" : "removeNode"](); // non-IE or IE
            iframe = createIFrame(counter++);
        };
    </script>
</head>
<body>
    <input type="button" value="Start test task" onclick="iframe = createIFrame(counter++); setInterval('startTask()', 3000);" />
</body>
</html>

---

Child

Code:

---

<!DOCTYPE html>
<html>
<head>
    <title>Child</title>

    <script src="ExtJS or fake file goes here.js"></script>
</head>
<body>
    Hello from iframe!
</body>
</html>

---

fake.js (up to 5MB or so)

Code:

---

var someNamespace = {};
SomeNamespace.someLongNameJustToIncreaseSpace0 = function() { var a, b, c, d; }
SomeNamespace.someLongNameJustToIncreaseSpace1 = function() { var a, b, c, d; }
SomeNamespace.someLongNameJustToIncreaseSpace2 = function() { var a, b, c, d; }
...
SomeNamespace.someLongNameJustToIncreaseSpaceN = function() { var a, b, c, d; }

---