Hi Martin,
sorry for kicking in here:
I'm observing the same in my application during the initialization of a
relative simple table (smart table model) with 8 rows and under 50 lines
placed in a window with 9 buttons.
While there is no problem in modern Browsers (IE9, Chrome 24, Firefox
18, Opera 12, Safari 5) where the window is displayed nearly instantly
I'm having big problems in IE8.
The profiler shows 3400 calls to qx.event.Manager.removeListener which
takes approx. 8 seconds in IE8.
My question is: what is causing this tremendous amount of calls to
removeListener during initialization of the window/widget?
I've done a profile under Chrome 24 which indicates that a lot of calls
where caused by LayoutItems.destruct (removal of the "changeTheme" event
listener)
destruct : function()
{
// remove dynamic theme listener
qx.theme.manager.Appearance.getInstance().removeListener(
"changeTheme", this._onChangeTheme, this
);
and qx.ui.basic.Label.destruct where I found the removal oft the
"changeLocale" event listener.
destruct : function()
{
if (qx.core.Environment.get("qx.dynlocale")) {
qx.locale.Manager.getInstance().removeListener("changeLocale",
this._onChangeLocale, this);
}
I've disabled the dynamic local change feature (environment qx.dynlocale
set to false in config.json) and commented out adding/removal of the
"changeTheme" event listener in LayoutItems which dropped initialization
of the window mentioned above from ~12 seconds to 2-3 seconds.
It seems that onn legacy browsers removeListener becomes very time
consuming especially for events added to singletons which have a lot of
added listeners (qx.theme.manager.Appearance and qx.locale.Manager).
I think two things may help running larger apps on IE legacy browsers:
1. Implement a hash based removeListener (as suggested by Thomas).
2. Support a similar environment setting in order to disable dynamic
theme change (eg. qx.dynthemechange).
3. Investigate why there are obviously so many
instatiations/destructions in this situation.
Best regards
Dietrich
Am 12.11.2012 13:12, schrieb Martin Wittemann:
> Hey,
>
>> in my qx.event.Manager.js#654
>>
>> the entryList is sequentially looped:
>>
>> for (var i=0, l=entryList.length; i<l; i++)
>> {
>> entry = entryList[i];
>> if (entry.handler === listener && entry.context === self)
>> ...
>>
>> Now the debugger tells me that in my case
>>
>> entryList.length == 53033 (!!!many items!!!)
>>
>> so everything gets very slow.
>>
>> 1) Does this show some problem in my code or are all qooxdoo events inside
>> entryList
>> and the huge number is normal?
> Well, it depends on the application size. If its a huge application, a number
> of 53k listeners is possible, especially when using data binding. So thats
> nothing I would worry about.
>
>> 2) Shouldn't the access to entryList be via a hashtable?
> And what would the key be? Listener and context could be two complex
> widgets...
>
> Did you profile how much this is impacting the overall performance? If its
> enough, we might consider a bug report for that.
>
> Regards,
> Martin
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
