Reclaiming memory from widgets

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

Reclaiming memory from widgets

Dave Baggett
What is the right thing to do to permanently dispose of a widget? Should I be called widget.destroy()? I ask because when I call that on a container it seems to leave the container's children around. Should I be doing a container.removeAll() and hook the _afterRemoveChild callback to do a .destroy() in there?

Basically, I want to make a whole bunch of widgets disappear so I can reclaim their memory.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

fritz
Dave,

from Tobi Oetiker:

Use the following mixin (include it in Application.js, then you can use it
everywhere):

             // Allow destruction of all children of a widget
             qx.Class.include(qx.ui.core.Widget, YOURAPP.ui.MDestroyAll);

The mixin is attached, just put the right name in there (replace YOURAPP
both in the mixin and in the include statement above).

Then you can do:

  widget.destroyAll();
  widget.destroy();

Or you could add a function in the mixin doing both ...


Cheers,
Fritz

On Mon, 22 Nov 2010, Dave Baggett wrote:

>
> What is the right thing to do to permanently dispose of a widget? Should I be
> called widget.destroy()? I ask because when I call that on a container it
> seems to leave the container's children around. Should I be doing a
> container.removeAll() and hook the _afterRemoveChild callback to do a
> .destroy() in there?
>
> Basically, I want to make a whole bunch of widgets disappear so I can
> reclaim their memory.
>
> Dave
>
>
--
Oetiker+Partner AG tel: +41 62 775 99 03 (direct)
Fritz Zaucker                        +41 62 775 99 00 (switch board)
Aarweg 15                            +41 79 675 06 30 (mobile)
CH-4600 Olten                   fax: +41 62 775 99 05
Schweiz                         web: www.oetiker.ch
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

MDestroyAll.js (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Dave Baggett
Thanks, Fritz -- I had no idea. Devs: shouldn't destroyAll() become a standard part of the library?

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

MartinWittemann
Administrator
Hey,

> Thanks, Fritz -- I had no idea. Devs: shouldn't destroyAll() become a
> standard part of the library?

Thats a good questions. I can't imagine a reason why it should not be part of the framework. Has someone an other opinion?

Regards,
Martin
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Petr Kobalíček
Hi,

do we need all of this in a garbage collected language?

Best regards
- Petr

On Tue, Nov 23, 2010 at 5:49 PM, Martin Wittemann
<[hidden email]> wrote:

> Hey,
>
>> Thanks, Fritz -- I had no idea. Devs: shouldn't destroyAll() become a
>> standard part of the library?
>
> Thats a good questions. I can't imagine a reason why it should not be part of the framework. Has someone an other opinion?
>
> Regards,
> Martin
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Dave Baggett
Petr Kobalíček wrote
Hi,

do we need all of this in a garbage collected language?

Best regards
- Petr
Yes. As I am learning in my own app, there are many instances where you need to prod JavaScript to actually GC an object. Otherwise you get perpetual memory growth.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Ken MacDonald
I'm with Dave. I've been fighting with this for weeks now. Unfortunately, even when I've run the destroyAll() mentioned here and explicitly call IE's CollectGarbage() function, memory size seems unaffected and continually growing. IE seems perfectly willing to completely ignore hints or even explicitly telling it to take out the trash. After a few iterations through my app, IE's memory size gets up to about 900 Meg, and pagefile up to 1.5 Gig, at which time it just stops responding. In Firefox, it just works, of course.
Ken

Yes. As I am learning in my own app, there are many instances where you need
to prod JavaScript to actually GC an object. Otherwise you get perpetual
memory growth.

Dave

--
View this message in context: http://qooxdoo.678.n2.nabble.com/Reclaiming-memory-from-widgets-tp5764047p5767706.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

fritz
In reply to this post by Dave Baggett
As I said, thanks to Tobi.

I am wondering, what is the use case for removeAll() without destroying the
widgets?

That would only make sense to me, if I would add the widgets again later on.
Is something like that done in the framework somewhere?  Otherwise it would
perhaps even be possible to replace removeAll() by destroyAll() ...  after
some deprecation period, of course ...  or have a removeAll with a destroy
parameter.

Just curious, because there might be some reluctance to add more things to
qx.core.widget as this is the base for everything else and leads to a larger
foot print.

Cheers,
Fritz

On Tue, 23 Nov 2010, Dave Baggett wrote:

> Thanks, Fritz -- I had no idea. Devs: shouldn't destroyAll() become a
> standard part of the library?
>
> Dave
>
>

--
Oetiker+Partner AG tel: +41 62 775 99 03 (direct)
Fritz Zaucker                        +41 62 775 99 00 (switch board)
Aarweg 15                            +41 79 675 06 30 (mobile)
CH-4600 Olten                   fax: +41 62 775 99 05
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Joachim Baran
Hi!

On 23 November 2010 19:44, Fritz Zaucker <[hidden email]> wrote:
> That would only make sense to me, if I would add the widgets again later on.
> Is something like that done in the framework somewhere?  Otherwise it would
> perhaps even be possible to replace removeAll() by destroyAll()
  My I veto that, please. :) I use removeAll() and re-use the
components in other places afterwards.

> or have a removeAll with a destroy parameter.
  I would second that though.

Joachim

--
B.1079 Michael Smith Building
Faculty of Life Sciences
The University of Manchester
Oxford Road
Manchester
M13 9PT
United Kingdom

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

fritz
Hi Joachim,

On Tue, 23 Nov 2010, Joachim Baran wrote:

> Hi!
>
> On 23 November 2010 19:44, Fritz Zaucker <[hidden email]> wrote:

>> That would only make sense to me, if I would add the widgets again later on.
>> Is something like that done in the framework somewhere?  Otherwise it would
>> perhaps even be possible to replace removeAll() by destroyAll()

>  My I veto that, please. :) I use removeAll() and re-use the components in
> other places afterwards.

Ok ... could you explain what you are doing? Just for my (and perhaps
others') education?


>>  or have a removeAll with a destroy parameter.

>  I would second that though.

Cheers,
Fritz

--
Oetiker+Partner AG tel: +41 62 775 99 03 (direct)
Fritz Zaucker                        +41 62 775 99 00 (switch board)
Aarweg 15                            +41 79 675 06 30 (mobile)
CH-4600 Olten                   fax: +41 62 775 99 05
Schweiz                         web: www.oetiker.ch
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Joachim Baran
On 23 November 2010 20:01, Fritz Zaucker <[hidden email]> wrote:
> Ok ... could you explain what you are doing? Just for my (and perhaps
> others') education?
  There are several Composite objects on the screen and I move the
contents of them around -- depending on user interaction. In one
particular case I use removeAll, even though I mainly use remove and
then shift just one object around. So, the model associated with the
movable objects stays the same this way, whilst I can place them in
different 'categories' (the Composite objects).

Joachim

--
B.1079 Michael Smith Building
Faculty of Life Sciences
The University of Manchester
Oxford Road
Manchester
M13 9PT
United Kingdom

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Ken MacDonald
I am planning to use something like this for a system I'm working on, where I have several dozen Lists, with perhaps 1000 ListItems. Depending on user interaction, I want to show the corresponding Lists/Items for a different month, but instead of deleting all of the Items/lists, I want to re-use them by just changing the content and UserData, since IE especially is not good at giving back the memory. I am thinking I will keep references to the objects in a pool, and create more if needed, or use less if I don't need as many. removeAll() seems perfect for this as it stands now.
Ken

On Tue, Nov 23, 2010 at 3:10 PM, Joachim Baran <[hidden email]> wrote:
On 23 November 2010 20:01, Fritz Zaucker <[hidden email]> wrote:
> Ok ... could you explain what you are doing? Just for my (and perhaps
> others') education?
 There are several Composite objects on the screen and I move the
contents of them around -- depending on user interaction. In one
particular case I use removeAll, even though I mainly use remove and
then shift just one object around. So, the model associated with the
movable objects stays the same this way, whilst I can place them in
different 'categories' (the Composite objects).

Joachim


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

fritz
In reply to this post by Joachim Baran
On Tue, 23 Nov 2010, Joachim Baran wrote:

> On 23 November 2010 20:01, Fritz Zaucker <[hidden email]> wrote:
>> Ok ... could you explain what you are doing? Just for my (and perhaps
>> others') education?
>  There are several Composite objects on the screen and I move the
> contents of them around -- depending on user interaction. In one
> particular case I use removeAll, even though I mainly use remove and
> then shift just one object around. So, the model associated with the
> movable objects stays the same this way, whilst I can place them in
> different 'categories' (the Composite objects).

Thanks,
Fritz

--
Oetiker+Partner AG tel: +41 62 775 99 03 (direct)
Fritz Zaucker                        +41 62 775 99 00 (switch board)
Aarweg 15                            +41 79 675 06 30 (mobile)
CH-4600 Olten                   fax: +41 62 775 99 05
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

fritz
In reply to this post by Ken MacDonald
Thanks,
Fritz

On Tue, 23 Nov 2010, Ken MacDonald wrote:

> I am planning to use something like this for a system I'm working on, where
> I have several dozen Lists, with perhaps 1000 ListItems. Depending on user
> interaction, I want to show the corresponding Lists/Items for a different
> month, but instead of deleting all of the Items/lists, I want to re-use them
> by just changing the content and UserData, since IE especially is not good
> at giving back the memory. I am thinking I will keep references to the
> objects in a pool, and create more if needed, or use less if I don't need as
> many. removeAll() seems perfect for this as it stands now.
> Ken
>
> On Tue, Nov 23, 2010 at 3:10 PM, Joachim Baran <[hidden email]>wrote:
>
>> On 23 November 2010 20:01, Fritz Zaucker <[hidden email]> wrote:
>>> Ok ... could you explain what you are doing? Just for my (and perhaps
>>> others') education?
>>   There are several Composite objects on the screen and I move the
>> contents of them around -- depending on user interaction. In one
>> particular case I use removeAll, even though I mainly use remove and
>> then shift just one object around. So, the model associated with the
>> movable objects stays the same this way, whilst I can place them in
>> different 'categories' (the Composite objects).
>>
>> Joachim
>>
>>
>

--
Oetiker+Partner AG tel: +41 62 775 99 03 (direct)
Fritz Zaucker                        +41 62 775 99 00 (switch board)
Aarweg 15                            +41 79 675 06 30 (mobile)
CH-4600 Olten                   fax: +41 62 775 99 05
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
flj
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

flj
In reply to this post by Dave Baggett
Hi.

> I'm with Dave. I've been fighting with this for weeks now. Unfortunately,
> even when I've run the destroyAll() mentioned here and explicitly call IE's
> CollectGarbage() function, memory size seems unaffected and continually
> growing. IE seems perfectly willing to completely ignore hints or even
> explicitly telling it to take out the trash. After a few iterations through
> my app, IE's memory size gets up to about 900 Meg, and pagefile up to 1.5
> Gig, at which time it just stops responding. In Firefox, it just works, of
> course.

We have a similar problem. We found out it's not just calling the garbage collector or the destructor method on objects that needs to be done. IE looses memory when some bindings stand in spite of an object being no longer needed. For instance, adding an event listener to an object is likely to prevent if from being garbage collected, even if both the event generating object and the event processing objects are no longer needed and not referred from anywhere else.

As long as you deallocate all objects and remove listeners the same way you have done when you built and wired your objects, memory losses seem to stay low. We had a similar problem - mem usage was gowing up with several thousands of objects upon each refill of a table, even if using just a few dozen rows, since we had listeners for cell clicks added repeatedly. As soon as we fixed this, only a few (less than 10, it seems) object remain uncollected after each refill (I wasn't the one doing the tests, so please take what I just said with a grain of salt).

br,

flj


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
flj
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

flj
In reply to this post by Dave Baggett
Since our problem seems related to repeatedly setting listeners on objects, even if from different other objects, I'd suggest a mixin containing a safeAddListener() method to the listener object, which, besides calling addListener() on the object generating the event, should store listeners added to foreign objects in an array, and remove them in destroy(). It could also set all members to null in destroy(), to additionally help the garbage collector. This way, no dangling listeners would stay around for an object you destroy explicitly. Some execution overhead would occur, but mem losses would be a lot less probable.

But I need to do some experiments to confirm the problem - I hope to be able to do this this year.

flj

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Jean-Baptiste BRIAUD -- Novlog
In reply to this post by Joachim Baran

On 23 nov. 2010, at 20:49, Joachim Baran wrote:

> Hi!
>
> On 23 November 2010 19:44, Fritz Zaucker <[hidden email]> wrote:
>> That would only make sense to me, if I would add the widgets again later on.
>> Is something like that done in the framework somewhere?  Otherwise it would
>> perhaps even be possible to replace removeAll() by destroyAll()
>  My I veto that, please. :) I use removeAll() and re-use the
> components in other places afterwards.
>
+1

To me, it sound like there is a confusion between destroyAll() and removeAll().

remove() and removeAl() should apply to a container and should remove the widget from the container.
Nothing to do with reclaiming memory.
Removing and re-adding a widget is very common way to speed up GUI by reusing widget instance.

destroy() sound like a destructor, isn'it ?


>>  or have a removeAll with a destroy parameter.
>  I would second that though.
>

I don't understand the need to mix 2 different things : reclaiming the memory and removing from container.
Why one would need to reclaim the memory with a remove ? In what case ?
Why not calling destroy on the rot container that in turn, internally, will loop and call remove + destroy ?

Code and API should show the intention as much as possible, so :
If a qooxdoo user call remove or removeAll it mean only removing widget from container. Remove should not make sense outside a container.
If a qooxdoo user call destroy or destroyAll it mean recovering memory, destructing a widget instance and this will also need to cascade the destroy it that widget is a container.

My 2 cents.


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

MartinWittemann
Administrator
Hey,

On 23 November 2010 19:44, Fritz Zaucker <[hidden email]> wrote:
That would only make sense to me, if I would add the widgets again later on.
Is something like that done in the framework somewhere?  Otherwise it would
perhaps even be possible to replace removeAll() by destroyAll()
My I veto that, please. :) I use removeAll() and re-use the
components in other places afterwards.
Totally agree. removeAll should never dispose the removed children.


To me, it sound like there is a confusion between destroyAll() and removeAll().

remove() and removeAl() should apply to a container and should remove the widget from the container.
Nothing to do with reclaiming memory.
Removing and re-adding a widget is very common way to speed up GUI by reusing widget instance.

destroy() sound like a destructor, isn'it ?
Exactly.


or have a removeAll with a destroy parameter.
I would second that though.


I don't understand the need to mix 2 different things : reclaiming the memory and removing from container.
Why one would need to reclaim the memory with a remove ? In what case ?
Why not calling destroy on the rot container that in turn, internally, will loop and call remove + destroy ?

Code and API should show the intention as much as possible, so :
If a qooxdoo user call remove or removeAll it mean only removing widget from container. Remove should not make sense outside a container.
If a qooxdoo user call destroy or destroyAll it mean recovering memory, destructing a widget instance and this will also need to cascade the destroy it that widget is a container.

What I don't like at the whole idea that the container should destroy objects he did not create. Usually, the object creating another objects is responsible for destroying them. With that in mind, i think that a removeAll including a destroy all could be done in the client code with a couple of lines:

var children = container.getChildren();
container.removeAll();
qx.util.DisposeUtil.disposeArray(children);

But i have to admit that removeAll should return an array containing all returned children. That would make it to a single line of code.

qx.util.DisposeUtil.disposeArray(container.removeAll());

What do you think about such a solution? That way, the dispose is kept at its place and its still a pretty nice API.

Best,
Martin

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Dave Baggett
MartinWittemann wrote
What I don't like at the whole idea that the container should destroy objects he did not create. Usually, the object creating another objects is responsible for destroying them. With that in mind, i think that a removeAll including a destroy all could be done in the client code with a couple of lines:

var children = container.getChildren();
container.removeAll();
qx.util.DisposeUtil.disposeArray(children);

But i have to admit that removeAll should return an array containing all returned children. That would make it to a single line of code.

qx.util.DisposeUtil.disposeArray(container.removeAll());

What do you think about such a solution? That way, the dispose is kept at its place and its still a pretty nice API.
That seems fine. It would also be great to have an additional page somewhere in the QooxDoo documentation outlining best practices for memory management, including coverage of IE's peculiarities and existing tools for tracking down leaks. Chrome's heap analyzer seems like the only reasonable tool out there right now, but I notice that dynaTrace Ajax has memory profiling on the list for the next release -- so maybe that will become another useful tool.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Reclaiming memory from widgets

Jean-Baptiste BRIAUD -- Novlog
In reply to this post by MartinWittemann

On 24 nov. 2010, at 10:29, Martin Wittemann wrote:
> removeAll should return an array containing all returned children. That would make it to a single line of code.
>
> qx.util.DisposeUtil.disposeArray(container.removeAll());
>
> What do you think about such a solution? That way, the dispose is kept at its place and its still a pretty nice API.
>
+1

What would be the point to keep widget instances when the container is dispose ?
A widget can't belongs to several container, so disposing the container should mean disposing the widgets inside.
That is not linked to previous point, but container.dispose could do the qx.util.DisposeUtil.disposeArray(container.removeAll())
That way, a simple call to dispose on any GUI node will dispose the sub tree.


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
12