Which package is needed for using the qx.io.remote.Rpc prototype?

classic Classic list List threaded Threaded
25 messages Options
12
p3k
Reply | Threaded
Open this post in threaded view
|

Which package is needed for using the qx.io.remote.Rpc prototype?

p3k
Hi

I am trying to evaluate qooxdoo’s JSON RPC support and quickly added the qx.Website package according to the docs at http://manual.qooxdoo.org/current/pages/website/requirements.html

However, the package obviously does not contain the qx object and so neither the desired qx.io.remote.Rpc prototype.

Thus, I guess I need a different package… if I just knew which one.

Any help is appreciated.

Best regards,
Tobi Schäfer
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

Thomas Herchenroeder
If you want to deploy the Rpc class you need to use the SDK [1].

T.

[1] http://qooxdoo.org/downloads#desktop


On 11/02/2012 02:00 PM, p3k wrote:

> Hi
>
> I am trying to evaluate qooxdoo’s JSON RPC support and quickly added the
> qx.Website package according to the docs at
> http://manual.qooxdoo.org/current/pages/website/requirements.html
>
> However, the package obviously does not contain the qx object and so neither
> the desired qx.io.remote.Rpc prototype.
>
> Thus, I guess I need a different package… if I just knew which one.
>
> Any help is appreciated.
>
> Best regards,
> Tobi Schäfer
>
>
>
>
> --
> View this message in context: http://qooxdoo.678.n2.nabble.com/Which-package-is-needed-for-using-the-qx-io-remote-Rpc-prototype-tp7581873.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
p3k
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

p3k
thron7-2 wrote
If you want to deploy the Rpc class you need to use the SDK [1].
Thanks for your reply, thron7-2.

So, does this mean the Rpc class is only usable from within a full fledged qooxdoo app?

In other words: if I would like to only use the Rpc class without the whole qooxdoo framework, how could I achieve this?

Any pointers are welcome.

Cheers,
tobi
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

Thomas Herchenroeder

On 11/05/2012 10:52 AM, p3k wrote:
> thron7-2 wrote
>> If you want to deploy the Rpc class you need to use the SDK [1].
> Thanks for your reply, thron7-2.
>
> So, does this mean the Rpc class is only usable from within a full fledged
> qooxdoo app?
>
> In other words: if I would like to only use the Rpc class without the whole
> qooxdoo framework, how could I achieve this?

Depends on your definition of "whole qooxdoo framework".
qx.io.remote.Rpc has certain dependencies. If you use the class, its
dependencie are also included in the build. These might be a few, but
that's it. Your built app only contains necessary code, not "the whole
framework".

T.


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
p3k
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

p3k
thron7-2 wrote
Depends on your definition of "whole qooxdoo framework".
Well, all I want is a JS file containing the code to call the Rpc method.

If I try it with the SDK and create a Website app how do I tell it to include the Rpc class and its dependencies?

Cheers,
tobi
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

fwolbring
Hello,

extracting and using code from the qooxdoo framework isn't as easy as grabbing the sources you need and move it to a side folder. You will need to copy the classloader as well. So I would suggest that you create a simple inline Application (<qooxdoo sdk path>/tool/bin/create-application.py -n <enter name here> -t inline -o <enter output path here>) and move all your existing files in the output folder. after that you can modify the index.html as needed and modify the entrypoint of the qooxdoo application (Application.js). Then you can access the needed classes from every where you wan't and you have the abillity to use qooxdoo widgets as well in your existing website. (I use this technique to display qooxdoo widgets in a typo 3 plugin page.)

I hope this helps a little bit

Cheers 

Frank Wolbring

On Mon, Nov 5, 2012 at 1:36 PM, p3k <[hidden email]> wrote:
thron7-2 wrote
> Depends on your definition of "whole qooxdoo framework".

Well, all I want is a JS file containing the code to call the Rpc method.

If I try it with the SDK and create a Website app how do I tell it to
include the Rpc class and its dependencies?

Cheers,
tobi




--
View this message in context: http://qooxdoo.678.n2.nabble.com/Which-package-is-needed-for-using-the-qx-io-remote-Rpc-prototype-tp7581873p7581896.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

Thomas Herchenroeder
In reply to this post by p3k

On 11/05/2012 01:36 PM, p3k wrote:
> thron7-2 wrote
>> Depends on your definition of "whole qooxdoo framework".
> Well, all I want is a JS file containing the code to call the Rpc method.

If you insist on a stand-alone file you have to create one yourself.
Basically, you create a skeleton, configure qx.ui.remote.Rpc to be the
sole "include" member and run the 'build' job.

But is it really important to have an individual file, just to provide
the Rpc class?

>
> If I try it with the SDK and create a Website app how do I tell it to
> include the Rpc class and its dependencies?

You don't, it's automatic, you just use the Rpc class in your code. The
main difference in the programming model between qx.Website and the SDK
is *library-based* vs. *generator-base* programming. Generator-based
programming covers all functionality that qx.Website does, but not the
other way round.

Library-based programming is the simple case where you have a (more or
less) self-contained JS library file, you include it in your index page,
and then include code that uses the library's API. This is the
qx.Website model. You have the library, its API doc, and then you are on
your own. The dependency to the library file is static.

Generator-base programming means you write your code against any of the
(public) framework classes, run the generator, and the generator creates
a loadable JS file (or some) and a specific loader which you then
include in your index page. This is the model the SDK supports. The
generator figures out which framework classes are needed by inspecting
your application code, and only includes those classes that are actually
relevant. The dependency to the set of framework classes is dynamic, the
generator creates a specific build each time you run it. In that the
build is much more specific and taylor-made than would be possible with
any library-based approach. Or, to put it another way: You are creating
a taylor-made library with every generator run, rather than dealing with
a static one.

T.

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
p3k
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

p3k
In reply to this post by fwolbring
fwolbring wrote
I hope this helps a little bit
Yes indeed, Frank, this helps a lot – thank you very much.
:)

I now created an app, removed all unwanted stuff and added the line

#require(qx.io.remote.Rpc)

to Application.js – after building it I get a relatively huge JS file of 664 KB but at least I can call the Rpc class.

Is there any chance to reduce the size of the output?

Cheers,
tobi
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

fwolbring
Hello,

Well, if you open the huge output file, you wll see that this file is allready shrinked and obfusecated. So all files needed by qooxdoo rpc class is in this file. Not more or less. So I don't think there is a way to reduce the file further more. The only way I know is to compress the file with the gz format. But I haven't done this before so I don't know how to acchieve this, sorry.

Cheers

Frank Wolbring

On Mon, Nov 5, 2012 at 2:33 PM, p3k <[hidden email]> wrote:
fwolbring wrote
> I hope this helps a little bit

Yes indeed, Frank, this helps a lot – thank you very much.
:)

I now created an app, removed all unwanted stuff and added the line



to Application.js – after building it I get a relatively huge JS file of 664
KB but at least I can call the Rpc class.

Is there any chance to reduce the size of the output?

Cheers,
tobi




--
View this message in context: http://qooxdoo.678.n2.nabble.com/Which-package-is-needed-for-using-the-qx-io-remote-Rpc-prototype-tp7581873p7581899.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
p3k
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

p3k
fwolbring wrote
Well, if you open the huge output file, you wll see that this file is
allready shrinked and obfusecated. So all files needed by qooxdoo rpc class
is in this file. Not more or less.
That’s a pity… Just from the API reference I think qooxdoo’s Rpc handling is one of the best for JavaScript I have seen so far.

It would be very nice to use (given that a few tests meet my expectations) but not for the price of more than half a megabyte of JS code.

I doubt that all the stuff in the output is really necessary, especially for the Rpc class, and I hardly can imagine there is not a way to leave out all the references to widget images, calendar data and the like…?

Cheers,
tobi

Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

Thomas Herchenroeder

On 11/05/2012 02:55 PM, p3k wrote:

> fwolbring wrote
>> Well, if you open the huge output file, you wll see that this file is
>> allready shrinked and obfusecated. So all files needed by qooxdoo rpc
>> class
>> is in this file. Not more or less.
> That’s a pity… Just from the API reference I think qooxdoo’s Rpc handling is
> one of the best for JavaScript I have seen so far.
>
> It would be very nice to use (given that a few tests meet my expectations)
> but not for the price of more than half a megabyte of JS code.
>
> I doubt that all the stuff in the output is really necessary, especially for
> the Rpc class, and I hardly can imagine there is not a way to leave out all
> the references to widget images, calendar data and the like…?

You're most probably right, but the Rpc class stems from a time when
functionality was more the focus than efficiency (which is probably also
true for a bunch of other classes). It's probably not a big issue to
change the implementation in a way that would get rid of a lot of
dependencies (e.g. making Rpc a 'qx.Boostrap.define' class), but then
you probably would also need to take other qx.io.remote.* classes under
scrutiny. But there are also other reasons to revamp the Rpc
implementation [1]. Comments, votes and patches welcome. Unfortunately,
there is so much work and only so little time...

T.

[1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=3975


------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
p3k
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

p3k
In reply to this post by Thomas Herchenroeder
thron7-2 wrote
If you insist on a stand-alone file you have to create one yourself.
Basically, you create a skeleton, configure qx.ui.remote.Rpc to be the
sole "include" member and run the 'build' job.
Well, I think I did that and the result is a huge JS file…  (please see my previous post)

thron7-2 wrote
[...] you just use the Rpc class in your code. [...] You are creating
a taylor-made library with every generator run, rather than dealing with
a static one.
More than 650 KB of JS code for one specific aspect is not really what I imagine taylor-made; it rather would meet my definition of “whole qooxdoo framework”.
;)

thron7-2 wrote
But is it really important to have an individual file, just to provide
the Rpc class?
From my point of view it is because all I want is to add qooxdoo’s RPC capabilities to a project that does not need the other features of this framework – as excellent as these might be (and I guess they are).

Cheers,
tobi
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

Thomas Herchenroeder
>> [...] you just use the Rpc class in your code. [...] You are creating
>> a taylor-made library with every generator run, rather than dealing with
>> a static one.
>
> More than 650 KB of JS code for one specific aspect is not really what I
> imagine taylor-made; it rather would meet my definition of "whole
> qooxdoo
> framework".
> ;)

I was not addressing the size issue (which can't be helped on short term)
but the programming model issue.

>> But is it really important to have an individual file, just to provide
>> the Rpc class?
>
> From my point of view it is because all I want is to add qooxdoo's RPC
> capabilities to a project that does not need the other features of this
> framework, as excellent as these might be (and I guess they are).

Again, you are mistaking my argument. I was not trying to advertise other
features of the framework, but to advertise using the tool chain rather
than programming against a static library.

T.



------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Which package is needed for using the qx.io.remote.Rpc prototype?

Burak Arslan-2
In reply to this post by p3k
On 11/05/12 15:33, p3k wrote:
> I get a relatively huge JS file of 664
> KB but at least I can call the Rpc class.
>
> Is there any chance to reduce the size of the output?


Did you run the google closure compiler on the resulting file? it also
helps reducing the code size from qooxdoo's build job.

burak

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

qx.event.Manager.js#654 slow?

Marcel Ruff-3
In reply to this post by p3k
Hi,

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?

2) Shouldn't the access to entryList be via a hashtable?

Thank you
Marcel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.event.Manager.js#654 slow?

MartinWittemann
Administrator
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.event.Manager.js#654 slow?

Thomas Herchenroeder

On 11/12/2012 01:12 PM, Martin Wittemann wrote:
>> 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...
>

If both are widgets we could hash over their object registry number.

T.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.event.Manager.js#654 slow?

Marcel Ruff-3
In reply to this post by MartinWittemann
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.
I have a qx.ui.table.model.Simple which has many CellEditors, probably
it is related to them, but currently only filled with a few rows.
In future some 12'000 rows will be entered.

>> 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...
The hash value or a compound key string of both above or, a hashtable of the first which contains a
hashtable of the second.

>
> Did you profile how much this is impacting the overall performance? If its enough, we might consider a bug report for that.
The current Firefox stops processing and a popup tells if we want to stop the app
because of slow execution. When I enter debugger then it displays above loop.
On a 8-core 3.4GHz Linux.

Thank you
Marcel


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.event.Manager.js#654 slow?

Dietrich Streifert
In reply to this post by MartinWittemann
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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.event.Manager.js#654 slow?

MartinWittemann
Administrator
Hey,

> 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).
I agree with you on that. Could you open up a report for that so I can work on it?

> 3. Investigate why there are obviously so many
> instatiations/destructions in this situation.

This would also be a bug, together with bullet point 1. We need to find a solution for the problem you described and 1, is a solution which might help so solve point 3 but it is not certain that its the only valid and best way to fix it.

Regards,
Martin
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of 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_122512
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
12