qooxdoo memory management

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

qooxdoo memory management

stefan.hansel

Hi there,
we are working on a bigger RAP application and as others do face the problem, that memory consumption of a single-page application increases very fast in IE.

To track bugs down I started to write a really simple qooxdoo-test-app trying to reproduce the problem and this wasn't to hard to achieve just by creating and destroying a lot of qx.ui.basic.Labels's in a row (and doing nothing else which could cause a leak).

After 3000 Labels the IE7 memory is over 180MB (testet with 0.7.3 and 8.0). Considering the Label to be one of the simplest qooxdoo-widgets, I think this is unacceptable.

The last 3 days I read a lot about IE memory problems, lazy garbage collection, circular references, object pooling and the like ... nevertheless I came to the conclusion that though it might not be easy, even without object pooling it should be possible to have a constant memory consuption in IE7 in the above scenario.

As sort of a proof I built the scenario (creating/destroying a simple widget a lot of times) with dojo-toolkit'-Textbox and Google Web Toolkit-Labels.
Both don't have any sort of object pooling and both leave IE7s memory constantly under 27MB (GWT) or 55MB (dojo) even for >20.000 (!) created and destroyed widgets (though Dojo seems to leak a VERY tiny bit as well). This is a huge difference to qooxdoo for sure.

I'm not sure, whether I'm doing anything wrong with qooxdoo. I played around with calling 'destroy' und 'dispose'-functions, flushed the qx.core.queue.Dipose-object and did several other things - nothing of which helped.

Can anyone give me hints of what to do in qooxdoo to have a constant memory allocation ?
I now that object pooling might be a way, BUT in my opinion object pooling in this case is just hiding the fact that there is a memory problem.

I planned to provide my qooxdoo-(0.8)-script, as well as GWT and Dojo examples of the same scenario as a comparison.
Unfortunataly the newsgroup doesn't accept this - any idea how i can provide this ?


Your help is much appreciated.

Kind Regards,
Stefan Hansel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

stefan.hansel

At least the sourcecode for the qooxdoo app ... if wanted I'll provide dojo + gwt source-code as well.
--------
qx.Class.define("Application",
{
extend : qx.application.Standalone,

members :
{
map : new Array(),
offset : 0,
refresh: function(e) {
for ( var int = 0; int < 100; int++) {
// delete old label
if (this.map[int]) {
this.map[int].destroy();
this.map[int].dispose();
this.map[int]=null;
delete this.map[int];
}

// create new one
var label = new qx.ui.basic.Label(this.offset + "Test Test Test Test Test Test Test" );
this.getRoot().add(label, {
left : 50,
top : 50 + int*20
});
this.map[int]=label;
label=null;
this.offset++;
}


qx.event.Timer.once(this.refresh, this, 500);
},

main : function()
{
// Call super class
this.base(arguments);

this.refresh();
}
}
});
--------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Andreas Ecker
In reply to this post by stefan.hansel
Hi Stefan,

thanks for your input.

> I planned to provide my qooxdoo-(0.8)-script, as well as GWT and Dojo
> examples of the same scenario as a comparison.
> Unfortunataly the newsgroup doesn't accept this - any idea how i can
> provide this ?

Regarding the (I suppose larger) files, you could just send them to me
directly, so I'll dispatch them here and we could have a closer look.
Thanks,

Andreas

--
Andreas Ecker
Project Lead
http://qooxdoo.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Jim Hunter
In reply to this post by stefan.hansel
You may not want to do pooling, but it has two really nice side effects:
1) It gets rid of your memory creep
2) It makes your program faster. It is much faster to re-use an object then it is to create a new one.

I spent about a week changing my large application over to using pooling and it is so much faster now it's not funny. My web application runs much faster then the Win32 version that it mimics. I used the pooling class that is in the contributions branch with just a few modifications to allow me to also pool tables. You may not want to do pooling, but I highly recommend it! The one thing to watch out for that is not covered in the pooling class are events listeneres. You need to remove the event listeners when you pool objects otherwise they start to accumulate and you get multiple actions firing for a single event. I 'discovered' this the hard way.

Jim


On Wed, Aug 13, 2008 at 1:47 AM, <[hidden email]> wrote:

Hi there,
we are working on a bigger RAP application and as others do face the problem, that memory consumption of a single-page application increases very fast in IE.

To track bugs down I started to write a really simple qooxdoo-test-app trying to reproduce the problem and this wasn't to hard to achieve just by creating and destroying a lot of qx.ui.basic.Labels's in a row (and doing nothing else which could cause a leak).

After 3000 Labels the IE7 memory is over 180MB (testet with 0.7.3 and 8.0). Considering the Label to be one of the simplest qooxdoo-widgets, I think this is unacceptable.

The last 3 days I read a lot about IE memory problems, lazy garbage collection, circular references, object pooling and the like ... nevertheless I came to the conclusion that though it might not be easy, even without object pooling it should be possible to have a constant memory consuption in IE7 in the above scenario.

As sort of a proof I built the scenario (creating/destroying a simple widget a lot of times) with dojo-toolkit'-Textbox and Google Web Toolkit-Labels.
Both don't have any sort of object pooling and both leave IE7s memory constantly under 27MB (GWT) or 55MB (dojo) even for >20.000 (!) created and destroyed widgets (though Dojo seems to leak a VERY tiny bit as well). This is a huge difference to qooxdoo for sure.

I'm not sure, whether I'm doing anything wrong with qooxdoo. I played around with calling 'destroy' und 'dispose'-functions, flushed the qx.core.queue.Dipose-object and did several other things - nothing of which helped.

Can anyone give me hints of what to do in qooxdoo to have a constant memory allocation ?
I now that object pooling might be a way, BUT in my opinion object pooling in this case is just hiding the fact that there is a memory problem.

I planned to provide my qooxdoo-(0.8)-script, as well as GWT and Dojo examples of the same scenario as a comparison.
Unfortunataly the newsgroup doesn't accept this - any idea how i can provide this ?


Your help is much appreciated.

Kind Regards,
Stefan Hansel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Derrell Lipman
On Wed, Aug 13, 2008 at 11:33 AM, Jim Hunter <[hidden email]> wrote:
The one thing to watch out for that is not covered in the pooling class are events listeneres. You need to remove the event listeners when you pool objects otherwise they start to accumulate and you get multiple actions firing for a single event. I 'discovered' this the hard way.

Jim, it would probably be quite useful for others if you could provide a patch to the maintainer of the pooling class that caused that class to properly clean up event listeners.

Derrell
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Jim Hunter
At this point, I have not created a 'global' way of doing it. I got very close yesterday, but 'time to go home' came and I had done 4 late night sessions in a row so I put down the keyboard and went home. If I get it fixed in a global way today, I will send the author a patch.
Thanks for your suggestion yesterday, it got me very close to getting this solved.

Jim



On Wed, Aug 13, 2008 at 8:35 AM, Derrell Lipman <[hidden email]> wrote:
On Wed, Aug 13, 2008 at 11:33 AM, Jim Hunter <[hidden email]> wrote:
The one thing to watch out for that is not covered in the pooling class are events listeneres. You need to remove the event listeners when you pool objects otherwise they start to accumulate and you get multiple actions firing for a single event. I 'discovered' this the hard way.

Jim, it would probably be quite useful for others if you could provide a patch to the maintainer of the pooling class that caused that class to properly clean up event listeners.

Derrell
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Petr Kobalíček
Integrated pooling directly to qooxdoo for faster execution can be
great, I will vote for it :-)

But, for me is interesting footprint of GWT

- Petr

2008/8/13 Jim Hunter <[hidden email]>:

> At this point, I have not created a 'global' way of doing it. I got very
> close yesterday, but 'time to go home' came and I had done 4 late night
> sessions in a row so I put down the keyboard and went home. If I get it
> fixed in a global way today, I will send the author a patch.
> Thanks for your suggestion yesterday, it got me very close to getting this
> solved.
>
> Jim
>
>
>
> On Wed, Aug 13, 2008 at 8:35 AM, Derrell Lipman
> <[hidden email]> wrote:
>>
>> On Wed, Aug 13, 2008 at 11:33 AM, Jim Hunter <[hidden email]> wrote:
>>>
>>> The one thing to watch out for that is not covered in the pooling class
>>> are events listeneres. You need to remove the event listeners when you pool
>>> objects otherwise they start to accumulate and you get multiple actions
>>> firing for a single event. I 'discovered' this the hard way.
>>
>> Jim, it would probably be quite useful for others if you could provide a
>> patch to the maintainer of the pooling class that caused that class to
>> properly clean up event listeners.
>>
>> Derrell
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>
>
>
> --
> Jim Hunter
>
> DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
> FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

stefan.hansel
In reply to this post by stefan.hansel
If was asked to provide GWT-code as well, since it's not much I'll post
the source here.

To create a webapp, you'll have to download GWT 1.5, and do the following
as described in the getting started guide (
http://code.google.com/webtoolkit/gettingstarted.html)

1) call 'projectCreator de.tolina.client.myApplication'
2) replace the generated source-code with the one below
3) call the generated 'MyApplication-compile'
4) start the generated HTML-site and watch memory-consumption.

If you want to debug or inspect javascript, read
http://code.google.com/support/bin/answer.py?answer=55203&topic=10212 
before, otherwise you won't be happy ;)
I couldn't spot any hot tricks - they don't even use the 'set innerHTML to
"" instead of removeChild to really release memory' trick often read on
newsgroups.

-------------------------

package de.tolina.client;


import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.Timer;
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.user.client.ui.TextBox;
import com.google.gwt.user.client.ui.VerticalPanel;
import com.google.gwt.user.client.ui.Widget;

public class MyApplication implements EntryPoint {
        static int offset = 0;
        List labels = new ArrayList();
        VerticalPanel vPanel = new VerticalPanel();

        public void onModuleLoad() {
                RootPanel.get().add(vPanel);

                Timer timer = new Timer() {
                        public void run() {
                                recreateLabels();
                        }
                };
                timer.scheduleRepeating(200);
        }

        public void recreateLabels() {
                // destroy old labels
                for (Iterator iterator = labels.iterator();
iterator.hasNext();) {
                        Widget label = (Widget) iterator.next();
                        label.removeFromParent();
                        iterator.remove();
                }

                // create new labels
                for (int i = 0; i < 500; i++) {
                        TextBox box = new TextBox();
                        box.setText(offset++ +"Test Test Test Test Test
Test Test" );
                        labels.add(box);
                        vPanel.add(box);
                }
        }
}



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Fabian Jakobs
Administrator
In reply to this post by stefan.hansel
Hi Stefan,

thank you for sharing these results. We will have a very close look at
the memory consumption of your script. I would not be surprised  if the
base line memory consumption of the qooxdoo app is above GWT and dojo as
qooxdoo widgets are probably more complex than those. But the increase
of memory consumption looks like a serious dispose bug somewhere in our
widget code, which we have to fix. We'll keep you up to date.

BTW to my knowledge the RAP guys at Innoopract are working to add widget
pooling in the next 0.8 based RAP release.


Best Fabian

> Hi there,
> we are working on a bigger RAP application and as others do face the
> problem, that memory consumption of a single-page application
> increases very fast in IE.
>
> To track bugs down I started to write a really simple qooxdoo-test-app
> trying to reproduce the problem and this wasn't to hard to achieve
> just by creating and destroying a lot of qx.ui.basic.Labels's in a row
> (and doing nothing else which could cause a leak).
>
> After 3000 Labels the IE7 memory is over 180MB (testet with 0.7.3 and
> 8.0). Considering the Label to be one of the simplest qooxdoo-widgets,
> I think this is unacceptable.
>
> The last 3 days I read a lot about IE memory problems, lazy garbage
> collection, circular references, object pooling and the like ...
> nevertheless I came to the conclusion that though it might not be
> easy, even without object pooling it should be possible to have a
> constant memory consuption in IE7 in the above scenario.
>
> As sort of a proof I built the scenario (creating/destroying a simple
> widget a lot of times) with dojo-toolkit'-Textbox and Google Web
> Toolkit-Labels.
> Both don't have any sort of object pooling and both leave IE7s memory
> constantly under 27MB (GWT) or 55MB (dojo) even for >20.000 (!)
> created and destroyed widgets (though Dojo seems to leak a VERY tiny
> bit as well). This is a huge difference to qooxdoo for sure.
>
> I'm not sure, whether I'm doing anything wrong with qooxdoo. I played
> around with calling 'destroy' und 'dispose'-functions, flushed the
> qx.core.queue.Dipose-object and did several other things - nothing of
> which helped.
>
> Can anyone give me hints of what to do in qooxdoo to have a constant
> memory allocation ?
> I now that object pooling might be a way, BUT in my opinion object
> pooling in this case is just hiding the fact that there is a memory
> problem.
>
> I planned to provide my qooxdoo-(0.8)-script, as well as GWT and Dojo
> examples of the same scenario as a comparison.
> Unfortunataly the newsgroup doesn't accept this - any idea how i can
> provide this ?
>
>
> Your help is much appreciated.
>
> Kind Regards,
> Stefan Hansel
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Sebastian Werner
One thing which is wrong in your qooxdoo code is that you call dispose
and destroy. For widget destroy is the better alternative when you
really want to remove the element (which means from the DOM as well).
When you call dispose() afterwards this effect is torpedated.

Sebastian


Fabian Jakobs schrieb:

> Hi Stefan,
>
> thank you for sharing these results. We will have a very close look at
> the memory consumption of your script. I would not be surprised  if the
> base line memory consumption of the qooxdoo app is above GWT and dojo as
> qooxdoo widgets are probably more complex than those. But the increase
> of memory consumption looks like a serious dispose bug somewhere in our
> widget code, which we have to fix. We'll keep you up to date.
>
> BTW to my knowledge the RAP guys at Innoopract are working to add widget
> pooling in the next 0.8 based RAP release.
>
>
> Best Fabian
>
>> Hi there,
>> we are working on a bigger RAP application and as others do face the
>> problem, that memory consumption of a single-page application
>> increases very fast in IE.
>>
>> To track bugs down I started to write a really simple qooxdoo-test-app
>> trying to reproduce the problem and this wasn't to hard to achieve
>> just by creating and destroying a lot of qx.ui.basic.Labels's in a row
>> (and doing nothing else which could cause a leak).
>>
>> After 3000 Labels the IE7 memory is over 180MB (testet with 0.7.3 and
>> 8.0). Considering the Label to be one of the simplest qooxdoo-widgets,
>> I think this is unacceptable.
>>
>> The last 3 days I read a lot about IE memory problems, lazy garbage
>> collection, circular references, object pooling and the like ...
>> nevertheless I came to the conclusion that though it might not be
>> easy, even without object pooling it should be possible to have a
>> constant memory consuption in IE7 in the above scenario.
>>
>> As sort of a proof I built the scenario (creating/destroying a simple
>> widget a lot of times) with dojo-toolkit'-Textbox and Google Web
>> Toolkit-Labels.
>> Both don't have any sort of object pooling and both leave IE7s memory
>> constantly under 27MB (GWT) or 55MB (dojo) even for >20.000 (!)
>> created and destroyed widgets (though Dojo seems to leak a VERY tiny
>> bit as well). This is a huge difference to qooxdoo for sure.
>>
>> I'm not sure, whether I'm doing anything wrong with qooxdoo. I played
>> around with calling 'destroy' und 'dispose'-functions, flushed the
>> qx.core.queue.Dipose-object and did several other things - nothing of
>> which helped.
>>
>> Can anyone give me hints of what to do in qooxdoo to have a constant
>> memory allocation ?
>> I now that object pooling might be a way, BUT in my opinion object
>> pooling in this case is just hiding the fact that there is a memory
>> problem.
>>
>> I planned to provide my qooxdoo-(0.8)-script, as well as GWT and Dojo
>> examples of the same scenario as a comparison.
>> Unfortunataly the newsgroup doesn't accept this - any idea how i can
>> provide this ?
>>
>>
>> Your help is much appreciated.
>>
>> Kind Regards,
>> Stefan Hansel
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>  
>
>


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

stefan.hansel
>> I would not be surprised  if the base line memory consumption of the
qooxdoo app
>> is above GWT and dojo as qooxdoo widgets are probably more complex than
those.

No problem with that.

>> BTW to my knowledge the RAP guys at Innoopract are working to add
widget
>> pooling in the next 0.8 based RAP release.
Yeah I know - but I consider this a workaround to possible qooxdoo memory
problems, rather than a solution.

>> One thing which is wrong in your qooxdoo code is that you call dispose
>> and destroy. For widget destroy is the better alternative when you
>> really want to remove the element (which means from the DOM as well).
>> When you call dispose() afterwards this effect is torpedated.

Thanks for the clarification. Anyway - it doesn't change anything if the
methods are called in reverse order or if just one (destroy) is called.
I suppose in 0.7.3 the equivalent to 'destroy' is 'disconnect' ?
If this is called without dispose in 0.7.3-version of the script, the
behaviour stays the same as well.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Sebastian Werner
[hidden email] schrieb:

>>> I would not be surprised  if the base line memory consumption of the
> qooxdoo app
>>> is above GWT and dojo as qooxdoo widgets are probably more complex than
> those.
>
> No problem with that.
>
>>> BTW to my knowledge the RAP guys at Innoopract are working to add
> widget
>>> pooling in the next 0.8 based RAP release.
> Yeah I know - but I consider this a workaround to possible qooxdoo memory
> problems, rather than a solution.
>
>>> One thing which is wrong in your qooxdoo code is that you call dispose
>>> and destroy. For widget destroy is the better alternative when you
>>> really want to remove the element (which means from the DOM as well).
>>> When you call dispose() afterwards this effect is torpedated.
>
> Thanks for the clarification. Anyway - it doesn't change anything if the
> methods are called in reverse order or if just one (destroy) is called.
> I suppose in 0.7.3 the equivalent to 'destroy' is 'disconnect' ?
> If this is called without dispose in 0.7.3-version of the script, the
> behaviour stays the same as well.

Just destroy() is right for widgets, dispose() not, the combination is
also wrong. Even if the results are comparable at the moment.

No, 0.7.3 has no such option. There is no equivalent.

Sebastian


>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Fabian Jakobs
Administrator
In reply to this post by stefan.hansel
[hidden email] schrieb:

>>> I would not be surprised  if the base line memory consumption of the
>>>      
> qooxdoo app
>  
>>> is above GWT and dojo as qooxdoo widgets are probably more complex than
>>>      
> those.
>
> No problem with that.
>
>  
>>> BTW to my knowledge the RAP guys at Innoopract are working to add
>>>      
> widget
>  
>>> pooling in the next 0.8 based RAP release.
>>>      
> Yeah I know - but I consider this a workaround to possible qooxdoo memory
> problems, rather than a solution.
>  
I think you have to differentiate here. Even without any memory leaks it
is a good idea to pool widgets. It is always faster to reconfigure an
already existing widget than to dispose and create a new one. This is
not limited to qooxdoo. I guess a dojo application can benefit from
pooling in the same way. Anyway, we'll have to take a very close look at
the memory problems you have reported.

Best Fabian


>  
>>> One thing which is wrong in your qooxdoo code is that you call dispose
>>> and destroy. For widget destroy is the better alternative when you
>>> really want to remove the element (which means from the DOM as well).
>>> When you call dispose() afterwards this effect is torpedated.
>>>      
>
> Thanks for the clarification. Anyway - it doesn't change anything if the
> methods are called in reverse order or if just one (destroy) is called.
> I suppose in 0.7.3 the equivalent to 'destroy' is 'disconnect' ?
> If this is called without dispose in 0.7.3-version of the script, the
> behaviour stays the same as well.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

stefan.hansel
In reply to this post by Sebastian Werner
>> No, 0.7.3 has no such option. There is no equivalent.

Since I'm still hoping that there is an easy solution for RAP and qooxdoo
0.7.3:

How do I correctly get rid of a widget in 0.7.3 if not calling
disconnect() (or setParent(null) ) and then dispose() ?


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Sebastian Werner

Am 15.08.2008 um 17:40 schrieb [hidden email]:

>>> No, 0.7.3 has no such option. There is no equivalent.
>
> Since I'm still hoping that there is an easy solution for RAP and  
> qooxdoo
> 0.7.3:
>
> How do I correctly get rid of a widget in 0.7.3 if not calling
> disconnect() (or setParent(null) ) and then dispose() ?

dispose() is basically OK, but we do not have an option to remove the  
DOM node of such elements in 0.7.x. All JS references are destroyed  
correctly though.

Sebastian

>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

stefan.hansel
In reply to this post by Fabian Jakobs
>> Anyway, we'll have to take a very close look at the memory problems you
have reported.

Maybe to safe some time for further investigations:

- For current tests I just use destroy- and no dispose-calls.
- Using one class above Labels (i.e. Widgets) the memory consumption is
not as drastic (tested now only with 0.8-trunk).
  The (very !) minimal amount still rising (only on a now very large
widget sets) can be tracked down to arrays wich hold hash-values of
objects.
  Adding and removing from javascript-arrays with always changing ids
leaks on IE and can be reproduced without qooxdoo as well.
  Stuff like ObjectPool or Dispose-Queue suffer from that, but as I said
this is soooo small compared to the 180MB for 3000 Labels,
  that it can be deferred for the time being.
- playing around with qx.html.Element instead of Labels: don't suffer
memory-leaks as well when used to manipulate DOM.
- I'm a bit worried about the following lines in
DisposeUtil.disposeObject(obj,arr):

        if (obj[name] == null || !this.hasOwnProperty(name)) {
          continue;
        }
  Shouldn't it be !obj.hasOwnProperty(name) like in all other methods ?
  Increasing the disposeDebugLevel without changing this line, I get a lot
of error-messages on the console.
  Looks like __containerElement and __contentElement are not disposed for
each Label (and any other widget I suppose)

  Unfortunataly this doesn't seem to solve the problem with labels, but
I'm not sure whether IE is playing tricks on me and using
  some js-cache thus not taking my changes right now.
  In FF the dispose-error-messages vanish when changing DisposeUtil.

Kind regards
Stefan.




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Hugh Gibson-2
>   The (very !) minimal amount still rising (only on a now very
> large widget sets) can be tracked down to arrays wich hold
> hash-values of objects.
>   Adding and removing from javascript-arrays with always changing
> ids leaks on IE and can be reproduced without qooxdoo as well.

Very interesting. Is this fixed by using Objects? In which case it should
be easy to change.

Hugh

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Sebastian Werner
In reply to this post by stefan.hansel
[hidden email] schrieb:
>>> Anyway, we'll have to take a very close look at the memory problems you
> have reported.
>
> Maybe to safe some time for further investigations:
>
> - For current tests I just use destroy- and no dispose-calls.

Fine.

> - Using one class above Labels (i.e. Widgets) the memory consumption is
> not as drastic (tested now only with 0.8-trunk).
>   The (very !) minimal amount still rising (only on a now very large
> widget sets) can be tracked down to arrays wich hold hash-values of
> objects.

Wow. OK. So this means that there is something especially affecting
Labels. We will have a closer look on them.

>   Adding and removing from javascript-arrays with always changing ids
> leaks on IE and can be reproduced without qooxdoo as well.
>   Stuff like ObjectPool or Dispose-Queue suffer from that, but as I said
> this is soooo small compared to the 180MB for 3000 Labels,
>   that it can be deferred for the time being.

Maybe it helps to generate a new Array instead of setting the current
Array to length=0. Can you test this as well?

> - playing around with qx.html.Element instead of Labels: don't suffer
> memory-leaks as well when used to manipulate DOM.

Can you test qx.html.Label as well? This would help to differ between
pure Elements and the elements used in the widget Label class.

> - I'm a bit worried about the following lines in
> DisposeUtil.disposeObject(obj,arr):
>
>         if (obj[name] == null || !this.hasOwnProperty(name)) {
>           continue;
>         }
>   Shouldn't it be !obj.hasOwnProperty(name) like in all other methods ?

Ok, that was a typo. Is fixed in SVN. Thanks for the report. These are
the kind of bugs that are quite hard to track.

>   Increasing the disposeDebugLevel without changing this line, I get a lot
> of error-messages on the console.
>   Looks like __containerElement and __contentElement are not disposed for
> each Label (and any other widget I suppose)
>
>   Unfortunataly this doesn't seem to solve the problem with labels, but
> I'm not sure whether IE is playing tricks on me and using
>   some js-cache thus not taking my changes right now.
>   In FF the dispose-error-messages vanish when changing DisposeUtil.

Thank you for your continued support. Really appreciated.

Kind regards,

Sebastian

>
> Kind regards
> Stefan.
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

Sebastian Werner
>
>> - playing around with qx.html.Element instead of Labels: don't suffer
>> memory-leaks as well when used to manipulate DOM.
>
> Can you test qx.html.Label as well? This would help to differ between
> pure Elements and the elements used in the widget Label class.

There was a major leak in the Label which kept links between the Locale
manager and the label intact, even for disposed Labels. This is now
fixed in trunk. Maybe you have some time to do your checks again. Thanks.

Sebastian

>
>> - I'm a bit worried about the following lines in
>> DisposeUtil.disposeObject(obj,arr):
>>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo memory management

stefan.hansel
Have some great and some 'bad' news:

great: the big memory problems of labels are gone
'bad': My claim that ui.core.Widgets have no memory-problem from the last
post was wrong.
This was from a test, where widgets were created and destroyed instantly,
without adding them to the root.

My current measures are as follows (done on windows xp sp2, IE7), I did
all the measures with a new testclass now (attached below).
All widgets/elements are made visible in the DOM and then removed again.

----------------
qooxdoo beta 1
----------------
 10.000 qx.ui.core.Widgets: 40MB leak
  3.000 qx.ui.basic.labels: stopped test, because massive memory leak

------------------
trunk (rev 15821)
------------------

  10.000 qx.ui.core.Widgets: 40MB leak
  10.000 qx.ui.basic.Labels  40MB leak

 100.000 qx.html.Labels:      7MB leak

------------------
trunk (rev 15821)
------------------
 changed, so that objects are not stored in object-registry

 100.000 qx.html.Labels:      no leak     <- as I said - 7MB on 100.000
elements without this fix is not relevant for now


--------------- test source --------
/**
 * Label-Creator
 */
qx.Class.define("custom.Application",
{
  extend : qx.application.Standalone,

  members :
  {
    map : new Array(),
    htmlRootElement : null,
    offset : 0,
    masterLabel : null,
 
    testHTMLElement: function() {
      var popped;
      while (popped=this.map.pop()) {
        popped.dispose();
        popped=null;
      }

      for ( var i = 0; i < 500; i++) {
        var qxElement = new qx.html.Label;
        qxElement.setContent(this.offset + "Test");
 
        this.htmlRootElement.add(qxElement);
 
        this.map.push(qxElement);
        this.offset++;
      }

      this.masterLabel.setContent("Widget Count: "+this.offset);
      qx.event.Timer.once(this.testHTMLElement, this, 300);
    },
 
    testWidgets: function() {
      var popped;
      while (popped=this.map.pop()) {
        popped.destroy();
        popped=null;
      }
 
      for ( var i = 0; i < 100; i++) {
 
        // toggle comment to switch between Labels and widgets
        var label=new qx.ui.basic.Label(this.offset + "Test");
        //var label=new qx.ui.core.Widget();
        //label.getContentElement().setAttribute("text", this.offset +
"Test");
 
        this.getRoot().add(label, {
          left : 50,
          top : 50 + i*20
        });
 
        this.map.push(label);
 
        this.offset++;
      }
 
      this.masterLabel.setContent("Widget Count: "+this.offset);
      qx.event.Timer.once(this.testWidgets, this, 300);
    },
 
 
    main : function()
    {
      // Call super class
      this.base(arguments);
      this.masterLabel=new qx.ui.basic.Label();
      this.getRoot().add(this.masterLabel, {
        left : 200,
        top : 10
      });
 
      var body=qx.dom.Node.getBodyElement(document);
      this.htmlRootElement= new qx.html.Root(body);
 
      // toggle comment for different tests
      this.testHTMLElement();
      //this.testWidgets();
    }
  }
});


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
12