PDA

View Full Version : Slow on windowed forms close and IE complains



gbulfon
5 Aug 2009, 4:59 AM
Hello.
We already had this problem on some windowed forms when using Ext 2.1.
We postponed the problem because we had in plan to move to Ext 3.
We were confident that the problem may disappear, as there is no mention of it in the Ext 3 forum, and the Ext 2 forum talks about it and gives a possible solution by modification of the event listeners register/unregister code.
We moved to Ext 3, but, instead, we now happen to have the problem on every windowed form, even the less populated ones, and closing is also a lot slower than on 2.1 on firefox too.

A part from the slow closing, it's a big problem when IE complains asking the user "Stop the running script?".
Is there a solution for this?
How can I investigate the issue?
Thanx
Gabriele.

tryanDLS
5 Aug 2009, 5:25 AM
Hard to guess without seeing code. The IE error implies that you have some very long running process or infinite loop. This isn't happening with the base code, so it's something your app is doing.

5 Aug 2009, 5:26 AM
yeah, are you overnesting/etc? How about posting a publically available demo?

gbulfon
5 Aug 2009, 5:39 AM
There is nothing strange in the code.
Just:

this.win.close();

And the window contains a form panel with some widgets.
These widgets are created and added to the panel on initComponet by:

var tf=new Ext.form.TextField({...});

and added by:

new Ext.Panel({
....,
items:[ tf, ................... ]
});

I have 2 of these panels in some case, added into a tabbed panel.
Then just closing the window it happens.
If this is not enough, I will try to put up a test case.

5 Aug 2009, 6:10 AM
you say nothing strange, but without a test case with viewable (readable!) code, it's hard for more experienced developers to judge that.

gbulfon
7 Aug 2009, 2:50 AM
Sorry for the delay, I spent some time trying to prepare a test case.
I took the Desktop sample, added an icon to run a custom window
containing all the code of the failing window in my app.
Problem is that I had to take out all the server managed calls (stores and so on) and
change them into local data stores (SimpleStore).
That way the problem doesn't happen...

To try to figure out what's happening, I changed a config option of FireFox, the number of seconds before showing the "stop script" window, lowered to 1 second.
Then I entered my app, opened the window, closed the window, got the "stop script" request, and FireFox allows me to debug. So I could step the code to see what it was doing.
The window was already disappeared.
As expected, the problem seems around the "remove listeners" code inside ext-all, that takes long.

It's hard to make a test case, because it would not have all the application around.
What I can do, is create a demo user for you to see the running app and check it.

Let me know if this is good.
Gabriele.

gbulfon
31 Aug 2009, 3:13 AM
Hi, I could find where is the loop.

function _getCacheIndex(el, eventName, fn) { ... }

in ext-base. The lookup for event listeners to be unregistered is a cycle into a vector
containing more then 5000 objects. How can it be such a big listeners vector?
How can I lower the number of Ext internal listeners to my windowed form?

ext-user
2 Sep 2009, 6:27 AM
Hi Gabriele,

We have a similar issue. Were you able to fix your problem?

Thanks,
Mary

gbulfon
2 Sep 2009, 6:36 AM
Hi, yes I found a workaround, that at least work for our situation.
Because the majority of event listeners are created and mantained on application startup,
and they remain active throughout its life cycle, the most suffering situation is
when internal windows need to be closed, because its events are at the end of the
listeners vector: removing them requires Event to cycle through thousands of elements, until it reaches the end of the vector to find them.

So, I modified the ext-base-debug.js (and then with some effort also ext-base.js)
just in one function: _getCacheIndex(...).
Instead of cycling all the elements, I let it cycle in reverse mode, starting at the end,
and stopping once the element has been found.
Here is the code to be substituted (I commented out the original code):



// private
function _getCacheIndex(el, eventName, fn) {
/* var index = -1;
Ext.each(listeners, function (v,i) {
if(v && v[FN] == fn && v[EL] == el && v[TYPE] == eventName) {
index = i;
}
});
return index;*/
var index = -1;
var len=listeners.length;
for(var i=len-1;i>=0;--i) {
var v=listeners[i];
if(v && v[FN] == fn && v[EL] == el && v[TYPE] == eventName) {
index = i;
break;
}
}
return index;
}


That was easier at the moment.
Implementing a structured listeners, divided per element id,
required much more modifications.
So I opted for this quick temporary solution.

Bye!
Gabriele.

ext-user
3 Sep 2009, 6:58 AM
Thanks for your quick response!
I'll try that out.


Mary

ext-user
4 Sep 2009, 9:57 AM
Hi Gabriele,

Your theory looks correct, but the solution does not work in our situation:

It works for you because your problem happens on closing a window component, which will always be at the end of the list.

But our problem happens on closing tabs, where the user has a choice of closing the first created tab or the last created tab.

With the original code I got the "Script running too slow" error when closing the last created tab, but not when closing the first created tab. With your change, I got reverse results!

Any more ideas?!

Thanks,
Mary