IE & memory management

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

IE & memory management

Jim Hunter
I am running into a troubling situation and am looking for a little help. My application re-uses 'tool windows' to display new information. It does so by removing all children (using a function I wrote to iterate through all children, destroy them (they iterate their children before destroying themselves). Then it destroys itself. Then I add the new contents to the tool window. In FireFox (all versions) I have no problems and the page renders in the same amount of time every time I bring it up. In IE (all versions 6-8), it takes longer and longer to render each time I bring up the tool window (I am using a qx.ui.layout.DockLayout as the main body of the tool window). And when I say longer, it goes from 2 seconds to 5 seconds to 9 seconds to 15 seconds to 25 seconds etc. It gets out of control very quickly.
Has anyone come up with a way to manage this or even eliminate the problem? To me, it looks like the objects are not getting destroyed in memory and it's causing IE to start choking on them and doesn't release them as it should.
Here is the function I use to clean out the tool before I add more objects to it:

disposeChildren:function()
{
    try{if(typeof this.hasChildren!='undefined')
    {
        if(this.hasChildren()==true)
        {
            this.forEachChild(function(chld)
            {
                chld.disposeChildren();
                chld.setParent(null);
                chld.dispose();
                qx.ui.core.Widget.flushGlobalQueues();
            });
        }
    }}
    catch(e)
    {
        try{this.setParent(null);
            this.dispose();
        }
        catch(e){}
    }
}



Any assistance would be greatly appreciated as we absolutely need to have IE working somewhat like FireFox. i know it's not going to work as fast, but we do need it to be consistant.

Thanks,
Jim



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

Hugh Gibson-2
> I am running into a troubling situation and am looking for a little
> help. My application re-uses 'tool windows' to display new
> information. It does so by removing all children (using a function I
> wrote to iterate through all children, destroy them (they iterate
> their children before destroying themselves). Then it destroys
> itself. Then I add the new contents to the tool window.

Some questions - sorry if they are obvious:

Have you confirmed that memory use is growing - i.e. that the children
are being left around?

Have you looked at re-using children instances?

Do your tool windows come in just a few flavours - i.e. with standard
sets of children? If so you could save removing the children from the
tool windows and just re-use the tool windows.

Hugh

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

Jim Hunter
If I do a count of the children each time, it is the same (5, which at the place I am checking this is the base amount for the window before adding it's contents). I have not looked at physical memory, I assumed that was the issue since it compounds itself on every iteration.

I can not re-use the children, I have no idea what set of children are going to be in the tool, it is determined by the user at runtime. All I can do is take the contents from the server and add them to the window when that window gets used.

I have about 5 different types of windows, that is why I thought simply removing the children then re-populating the window would work, but in IE it doesn't work so well. FireFox works just fine.

In IE, if I clear the entire window before loading that tool window by hitting F5, the window loads fast, So I am going to try completely disposing the entire window each time to see if it does any better. Or perhaps I should also try and set each child control to null in my disposeChildren function. Perhaps IE would then remove them from memory. I just think IE is very slow on garbage collection (there are about 100 or more controls in the tool window each time it gets displayed and some of the controls are grids/tables.

Thanks for the help,
Jim



On Wed, Jul 2, 2008 at 11:06 PM, Hugh Gibson <[hidden email]> wrote:
> I am running into a troubling situation and am looking for a little
> help. My application re-uses 'tool windows' to display new
> information. It does so by removing all children (using a function I
> wrote to iterate through all children, destroy them (they iterate
> their children before destroying themselves). Then it destroys
> itself. Then I add the new contents to the tool window.

Some questions - sorry if they are obvious:

Have you confirmed that memory use is growing - i.e. that the children
are being left around?

Have you looked at re-using children instances?

Do your tool windows come in just a few flavours - i.e. with standard
sets of children? If so you could save removing the children from the
tool windows and just re-use the tool windows.

Hugh

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
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
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

simonb
In reply to this post by Jim Hunter
Hi Jim,

I am not sure which version of qx you are using, but I experienced a
very similar problem a long while back with qx 0.6.x.  My final
solution was to implement object pooling, and reuse pooled instances
rather than instantiating new ones all the time.  I added my Pool
class to the contribute project, and (from memory -- must have been a
year ago now) I think Fabian migrated it to qx 0.7.x.

Simon



On Thu, Jul 3, 2008 at 10:52 AM, Jim Hunter <[hidden email]> wrote:

> I am running into a troubling situation and am looking for a little help. My
> application re-uses 'tool windows' to display new information. It does so by
> removing all children (using a function I wrote to iterate through all
> children, destroy them (they iterate their children before destroying
> themselves). Then it destroys itself. Then I add the new contents to the
> tool window. In FireFox (all versions) I have no problems and the page
> renders in the same amount of time every time I bring it up. In IE (all
> versions 6-8), it takes longer and longer to render each time I bring up the
> tool window (I am using a qx.ui.layout.DockLayout as the main body of the
> tool window). And when I say longer, it goes from 2 seconds to 5 seconds to
> 9 seconds to 15 seconds to 25 seconds etc. It gets out of control very
> quickly.
> Has anyone come up with a way to manage this or even eliminate the problem?
> To me, it looks like the objects are not getting destroyed in memory and
> it's causing IE to start choking on them and doesn't release them as it
> should.
> Here is the function I use to clean out the tool before I add more objects
> to it:
>
> disposeChildren:function()
> {
>     try{if(typeof this.hasChildren!='undefined')
>     {
>         if(this.hasChildren()==true)
>         {
>             this.forEachChild(function(chld)
>             {
>                 chld.disposeChildren();
>                 chld.setParent(null);
>                 chld.dispose();
>                 qx.ui.core.Widget.flushGlobalQueues();
>             });
>         }
>     }}
>     catch(e)
>     {
>         try{this.setParent(null);
>             this.dispose();
>         }
>         catch(e){}
>     }
> }
>
>
>
> Any assistance would be greatly appreciated as we absolutely need to have IE
> working somewhat like FireFox. i know it's not going to work as fast, but we
> do need it to be consistant.
>
> Thanks,
> Jim
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

Jim Hunter
So how do you handle the scenario where one tool might have 20 Atoms on it, but the next iteration of that tool will have 1000? Do you simply just add new controls to the pool if needed allowing it to grow to the max size needed? Then when they are no longer needed, just set the parent to null? If I can't get what I am working on to solve the problem, I will look into your solution.

Thanks,
Jim


On Wed, Jul 2, 2008 at 11:28 PM, Simon Bull <[hidden email]> wrote:
Hi Jim,

I am not sure which version of qx you are using, but I experienced a
very similar problem a long while back with qx 0.6.x.  My final
solution was to implement object pooling, and reuse pooled instances
rather than instantiating new ones all the time.  I added my Pool
class to the contribute project, and (from memory -- must have been a
year ago now) I think Fabian migrated it to qx 0.7.x.

Simon



On Thu, Jul 3, 2008 at 10:52 AM, Jim Hunter <[hidden email]> wrote:
> I am running into a troubling situation and am looking for a little help. My
> application re-uses 'tool windows' to display new information. It does so by
> removing all children (using a function I wrote to iterate through all
> children, destroy them (they iterate their children before destroying
> themselves). Then it destroys itself. Then I add the new contents to the
> tool window. In FireFox (all versions) I have no problems and the page
> renders in the same amount of time every time I bring it up. In IE (all
> versions 6-8), it takes longer and longer to render each time I bring up the
> tool window (I am using a qx.ui.layout.DockLayout as the main body of the
> tool window). And when I say longer, it goes from 2 seconds to 5 seconds to
> 9 seconds to 15 seconds to 25 seconds etc. It gets out of control very
> quickly.
> Has anyone come up with a way to manage this or even eliminate the problem?
> To me, it looks like the objects are not getting destroyed in memory and
> it's causing IE to start choking on them and doesn't release them as it
> should.
> Here is the function I use to clean out the tool before I add more objects
> to it:
>
> disposeChildren:function()
> {
>     try{if(typeof this.hasChildren!='undefined')
>     {
>         if(this.hasChildren()==true)
>         {
>             this.forEachChild(function(chld)
>             {
>                 chld.disposeChildren();
>                 chld.setParent(null);
>                 chld.dispose();
>                 qx.ui.core.Widget.flushGlobalQueues();
>             });
>         }
>     }}
>     catch(e)
>     {
>         try{this.setParent(null);
>             this.dispose();
>         }
>         catch(e){}
>     }
> }
>
>
>
> Any assistance would be greatly appreciated as we absolutely need to have IE
> working somewhat like FireFox. i know it's not going to work as fast, but we
> do need it to be consistant.
>
> Thanks,
> Jim
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
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
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

simonb
Hi again Jim,

In my case I used the pool primarily for window instances, where each
class of window had lots of menus, toolbars, toolbar buttons etc.
Some window types had hundred of widgets, so it became expensive to
create new window instances dozens of times.  Each new instance of a
class of window was exactly the same as any previous one, so it made
good sense to recycle used window instances.

Your case does sound a bit different to mine -- but pooling could
still work for you.  If you are using thousands of Atom instances,
then you might try pooling Atoms.  To make this work you may need to
use something like AtomFactory.getInstance() rather than using the new
operator to get Atom your instances.  Then you need to extend Atom to
a PoolableAtom, or add a Poolable mixin to each Atom that the
AtomFactory creates.  That way the AtomFactory can call a teardown()
each time an Atom instance is returned to the pool, and a setup() each
time an Atom instance is pulled out of the pool.

The result of all this is that the maximum number of Atom instances
that are ever created is equal to the maximum number that are in use
at any one time, rather than the sum of all instances that were ever
in use.  If there is a significant difference between these two
figures, pooling might be worthwhile.

Of course, the above assumes that the root of the problem is that IE
fails to garbage collect disposed instances efficiently.  I did some
intensive testing of this a couple of years back and found that IE6 in
particular had very unreliable garbage collection within the context
of a single, long running page (i.e., when the browser is never asked
to reload the page).

Cheers,

Simon




On Fri, Jul 4, 2008 at 1:13 AM, Jim Hunter <[hidden email]> wrote:

> So how do you handle the scenario where one tool might have 20 Atoms on it,
> but the next iteration of that tool will have 1000? Do you simply just add
> new controls to the pool if needed allowing it to grow to the max size
> needed? Then when they are no longer needed, just set the parent to null? If
> I can't get what I am working on to solve the problem, I will look into your
> solution.
>
> Thanks,
> Jim
>
>
> On Wed, Jul 2, 2008 at 11:28 PM, Simon Bull <[hidden email]> wrote:
>>
>> Hi Jim,
>>
>> I am not sure which version of qx you are using, but I experienced a
>> very similar problem a long while back with qx 0.6.x.  My final
>> solution was to implement object pooling, and reuse pooled instances
>> rather than instantiating new ones all the time.  I added my Pool
>> class to the contribute project, and (from memory -- must have been a
>> year ago now) I think Fabian migrated it to qx 0.7.x.
>>
>> Simon
>>
>>
>>
>> On Thu, Jul 3, 2008 at 10:52 AM, Jim Hunter <[hidden email]> wrote:
>> > I am running into a troubling situation and am looking for a little
>> > help. My
>> > application re-uses 'tool windows' to display new information. It does
>> > so by
>> > removing all children (using a function I wrote to iterate through all
>> > children, destroy them (they iterate their children before destroying
>> > themselves). Then it destroys itself. Then I add the new contents to the
>> > tool window. In FireFox (all versions) I have no problems and the page
>> > renders in the same amount of time every time I bring it up. In IE (all
>> > versions 6-8), it takes longer and longer to render each time I bring up
>> > the
>> > tool window (I am using a qx.ui.layout.DockLayout as the main body of
>> > the
>> > tool window). And when I say longer, it goes from 2 seconds to 5 seconds
>> > to
>> > 9 seconds to 15 seconds to 25 seconds etc. It gets out of control very
>> > quickly.
>> > Has anyone come up with a way to manage this or even eliminate the
>> > problem?
>> > To me, it looks like the objects are not getting destroyed in memory and
>> > it's causing IE to start choking on them and doesn't release them as it
>> > should.
>> > Here is the function I use to clean out the tool before I add more
>> > objects
>> > to it:
>> >
>> > disposeChildren:function()
>> > {
>> >     try{if(typeof this.hasChildren!='undefined')
>> >     {
>> >         if(this.hasChildren()==true)
>> >         {
>> >             this.forEachChild(function(chld)
>> >             {
>> >                 chld.disposeChildren();
>> >                 chld.setParent(null);
>> >                 chld.dispose();
>> >                 qx.ui.core.Widget.flushGlobalQueues();
>> >             });
>> >         }
>> >     }}
>> >     catch(e)
>> >     {
>> >         try{this.setParent(null);
>> >             this.dispose();
>> >         }
>> >         catch(e){}
>> >     }
>> > }
>> >
>> >
>> >
>> > Any assistance would be greatly appreciated as we absolutely need to
>> > have IE
>> > working somewhat like FireFox. i know it's not going to work as fast,
>> > but we
>> > do need it to be consistant.
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> >
>> >
>> > -------------------------------------------------------------------------
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> > _______________________________________________
>> > qooxdoo-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> 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
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

Jim Hunter
Thanks, my partner and I had come up with the same answer. That is, to use a factory pattern for each class that we use. I have not got to that point yet as it turns out that my disposeChildren function that I wrote was actually not working as I suspected and I am still tweaking it to see if using that alone will give me better results. I am not going to be doing any more work on it until next Monday, so I get to sit on it until then.

Thanks for your assistance.

Jim


On Thu, Jul 3, 2008 at 5:25 PM, Simon Bull <[hidden email]> wrote:
Hi again Jim,

In my case I used the pool primarily for window instances, where each
class of window had lots of menus, toolbars, toolbar buttons etc.
Some window types had hundred of widgets, so it became expensive to
create new window instances dozens of times.  Each new instance of a
class of window was exactly the same as any previous one, so it made
good sense to recycle used window instances.

Your case does sound a bit different to mine -- but pooling could
still work for you.  If you are using thousands of Atom instances,
then you might try pooling Atoms.  To make this work you may need to
use something like AtomFactory.getInstance() rather than using the new
operator to get Atom your instances.  Then you need to extend Atom to
a PoolableAtom, or add a Poolable mixin to each Atom that the
AtomFactory creates.  That way the AtomFactory can call a teardown()
each time an Atom instance is returned to the pool, and a setup() each
time an Atom instance is pulled out of the pool.

The result of all this is that the maximum number of Atom instances
that are ever created is equal to the maximum number that are in use
at any one time, rather than the sum of all instances that were ever
in use.  If there is a significant difference between these two
figures, pooling might be worthwhile.

Of course, the above assumes that the root of the problem is that IE
fails to garbage collect disposed instances efficiently.  I did some
intensive testing of this a couple of years back and found that IE6 in
particular had very unreliable garbage collection within the context
of a single, long running page (i.e., when the browser is never asked
to reload the page).

Cheers,

Simon




On Fri, Jul 4, 2008 at 1:13 AM, Jim Hunter <[hidden email]> wrote:
> So how do you handle the scenario where one tool might have 20 Atoms on it,
> but the next iteration of that tool will have 1000? Do you simply just add
> new controls to the pool if needed allowing it to grow to the max size
> needed? Then when they are no longer needed, just set the parent to null? If
> I can't get what I am working on to solve the problem, I will look into your
> solution.
>
> Thanks,
> Jim
>
>
> On Wed, Jul 2, 2008 at 11:28 PM, Simon Bull <[hidden email]> wrote:
>>
>> Hi Jim,
>>
>> I am not sure which version of qx you are using, but I experienced a
>> very similar problem a long while back with qx 0.6.x.  My final
>> solution was to implement object pooling, and reuse pooled instances
>> rather than instantiating new ones all the time.  I added my Pool
>> class to the contribute project, and (from memory -- must have been a
>> year ago now) I think Fabian migrated it to qx 0.7.x.
>>
>> Simon
>>
>>
>>
>> On Thu, Jul 3, 2008 at 10:52 AM, Jim Hunter <[hidden email]> wrote:
>> > I am running into a troubling situation and am looking for a little
>> > help. My
>> > application re-uses 'tool windows' to display new information. It does
>> > so by
>> > removing all children (using a function I wrote to iterate through all
>> > children, destroy them (they iterate their children before destroying
>> > themselves). Then it destroys itself. Then I add the new contents to the
>> > tool window. In FireFox (all versions) I have no problems and the page
>> > renders in the same amount of time every time I bring it up. In IE (all
>> > versions 6-8), it takes longer and longer to render each time I bring up
>> > the
>> > tool window (I am using a qx.ui.layout.DockLayout as the main body of
>> > the
>> > tool window). And when I say longer, it goes from 2 seconds to 5 seconds
>> > to
>> > 9 seconds to 15 seconds to 25 seconds etc. It gets out of control very
>> > quickly.
>> > Has anyone come up with a way to manage this or even eliminate the
>> > problem?
>> > To me, it looks like the objects are not getting destroyed in memory and
>> > it's causing IE to start choking on them and doesn't release them as it
>> > should.
>> > Here is the function I use to clean out the tool before I add more
>> > objects
>> > to it:
>> >
>> > disposeChildren:function()
>> > {
>> >     try{if(typeof this.hasChildren!='undefined')
>> >     {
>> >         if(this.hasChildren()==true)
>> >         {
>> >             this.forEachChild(function(chld)
>> >             {
>> >                 chld.disposeChildren();
>> >                 chld.setParent(null);
>> >                 chld.dispose();
>> >                 qx.ui.core.Widget.flushGlobalQueues();
>> >             });
>> >         }
>> >     }}
>> >     catch(e)
>> >     {
>> >         try{this.setParent(null);
>> >             this.dispose();
>> >         }
>> >         catch(e){}
>> >     }
>> > }
>> >
>> >
>> >
>> > Any assistance would be greatly appreciated as we absolutely need to
>> > have IE
>> > working somewhat like FireFox. i know it's not going to work as fast,
>> > but we
>> > do need it to be consistant.
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> >
>> >
>> > -------------------------------------------------------------------------
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> > _______________________________________________
>> > qooxdoo-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> 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
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
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
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

Jim Hunter
In reply to this post by simonb
Simon,

  I went to the repository and could not find the contributions area. Is there a way I could get a copy of your pool class? I am attempting to write one, it's coming along fine, but I would like to see how it differs from yours and perhaps I could make mine better looking at yours.

  Unfortunately, I have to 'strap' pooling onto an application that is already running with the least amount of code change. This is turning out to be the hardest part. My pooling class seems to work well, it's just shoe horning it into my app that is the fun part.

Thanks,

Jim


On Thu, Jul 3, 2008 at 5:25 PM, Simon Bull <[hidden email]> wrote:
Hi again Jim,

In my case I used the pool primarily for window instances, where each
class of window had lots of menus, toolbars, toolbar buttons etc.
Some window types had hundred of widgets, so it became expensive to
create new window instances dozens of times.  Each new instance of a
class of window was exactly the same as any previous one, so it made
good sense to recycle used window instances.

Your case does sound a bit different to mine -- but pooling could
still work for you.  If you are using thousands of Atom instances,
then you might try pooling Atoms.  To make this work you may need to
use something like AtomFactory.getInstance() rather than using the new
operator to get Atom your instances.  Then you need to extend Atom to
a PoolableAtom, or add a Poolable mixin to each Atom that the
AtomFactory creates.  That way the AtomFactory can call a teardown()
each time an Atom instance is returned to the pool, and a setup() each
time an Atom instance is pulled out of the pool.

The result of all this is that the maximum number of Atom instances
that are ever created is equal to the maximum number that are in use
at any one time, rather than the sum of all instances that were ever
in use.  If there is a significant difference between these two
figures, pooling might be worthwhile.

Of course, the above assumes that the root of the problem is that IE
fails to garbage collect disposed instances efficiently.  I did some
intensive testing of this a couple of years back and found that IE6 in
particular had very unreliable garbage collection within the context
of a single, long running page (i.e., when the browser is never asked
to reload the page).

Cheers,

Simon




On Fri, Jul 4, 2008 at 1:13 AM, Jim Hunter <[hidden email]> wrote:
> So how do you handle the scenario where one tool might have 20 Atoms on it,
> but the next iteration of that tool will have 1000? Do you simply just add
> new controls to the pool if needed allowing it to grow to the max size
> needed? Then when they are no longer needed, just set the parent to null? If
> I can't get what I am working on to solve the problem, I will look into your
> solution.
>
> Thanks,
> Jim
>
>
> On Wed, Jul 2, 2008 at 11:28 PM, Simon Bull <[hidden email]> wrote:
>>
>> Hi Jim,
>>
>> I am not sure which version of qx you are using, but I experienced a
>> very similar problem a long while back with qx 0.6.x.  My final
>> solution was to implement object pooling, and reuse pooled instances
>> rather than instantiating new ones all the time.  I added my Pool
>> class to the contribute project, and (from memory -- must have been a
>> year ago now) I think Fabian migrated it to qx 0.7.x.
>>
>> Simon
>>
>>
>>
>> On Thu, Jul 3, 2008 at 10:52 AM, Jim Hunter <[hidden email]> wrote:
>> > I am running into a troubling situation and am looking for a little
>> > help. My
>> > application re-uses 'tool windows' to display new information. It does
>> > so by
>> > removing all children (using a function I wrote to iterate through all
>> > children, destroy them (they iterate their children before destroying
>> > themselves). Then it destroys itself. Then I add the new contents to the
>> > tool window. In FireFox (all versions) I have no problems and the page
>> > renders in the same amount of time every time I bring it up. In IE (all
>> > versions 6-8), it takes longer and longer to render each time I bring up
>> > the
>> > tool window (I am using a qx.ui.layout.DockLayout as the main body of
>> > the
>> > tool window). And when I say longer, it goes from 2 seconds to 5 seconds
>> > to
>> > 9 seconds to 15 seconds to 25 seconds etc. It gets out of control very
>> > quickly.
>> > Has anyone come up with a way to manage this or even eliminate the
>> > problem?
>> > To me, it looks like the objects are not getting destroyed in memory and
>> > it's causing IE to start choking on them and doesn't release them as it
>> > should.
>> > Here is the function I use to clean out the tool before I add more
>> > objects
>> > to it:
>> >
>> > disposeChildren:function()
>> > {
>> >     try{if(typeof this.hasChildren!='undefined')
>> >     {
>> >         if(this.hasChildren()==true)
>> >         {
>> >             this.forEachChild(function(chld)
>> >             {
>> >                 chld.disposeChildren();
>> >                 chld.setParent(null);
>> >                 chld.dispose();
>> >                 qx.ui.core.Widget.flushGlobalQueues();
>> >             });
>> >         }
>> >     }}
>> >     catch(e)
>> >     {
>> >         try{this.setParent(null);
>> >             this.dispose();
>> >         }
>> >         catch(e){}
>> >     }
>> > }
>> >
>> >
>> >
>> > Any assistance would be greatly appreciated as we absolutely need to
>> > have IE
>> > working somewhat like FireFox. i know it's not going to work as fast,
>> > but we
>> > do need it to be consistant.
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> >
>> >
>> > -------------------------------------------------------------------------
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> > _______________________________________________
>> > qooxdoo-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> 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
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
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
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: IE & memory management

simonb
Hi Jim,

The qooxdoo-contrib project is hosted in a separate source code
repository at http://sourceforge.net/projects/qooxdoo-contrib/ .

My stuff is under /trunk/qooxdoo-contrib/WindowManager/

The classes of specific interest to you might be:

ext.core.Pool.js
ext/manager/object/WindowManager.js  (which uses Pool to recycle
Window instances)
ext/ui/window/Window.js (which is the managed class -- implements
setup/teardown).

Happy to help with any questions you might have about it...


Simon

On Thu, Jul 10, 2008 at 7:58 AM, Jim Hunter <[hidden email]> wrote:

> Simon,
>
>   I went to the repository and could not find the contributions area. Is
> there a way I could get a copy of your pool class? I am attempting to write
> one, it's coming along fine, but I would like to see how it differs from
> yours and perhaps I could make mine better looking at yours.
>
>   Unfortunately, I have to 'strap' pooling onto an application that is
> already running with the least amount of code change. This is turning out to
> be the hardest part. My pooling class seems to work well, it's just shoe
> horning it into my app that is the fun part.
>
> Thanks,
>
> Jim
>
>
> On Thu, Jul 3, 2008 at 5:25 PM, Simon Bull <[hidden email]> wrote:
>>
>> Hi again Jim,
>>
>> In my case I used the pool primarily for window instances, where each
>> class of window had lots of menus, toolbars, toolbar buttons etc.
>> Some window types had hundred of widgets, so it became expensive to
>> create new window instances dozens of times.  Each new instance of a
>> class of window was exactly the same as any previous one, so it made
>> good sense to recycle used window instances.
>>
>> Your case does sound a bit different to mine -- but pooling could
>> still work for you.  If you are using thousands of Atom instances,
>> then you might try pooling Atoms.  To make this work you may need to
>> use something like AtomFactory.getInstance() rather than using the new
>> operator to get Atom your instances.  Then you need to extend Atom to
>> a PoolableAtom, or add a Poolable mixin to each Atom that the
>> AtomFactory creates.  That way the AtomFactory can call a teardown()
>> each time an Atom instance is returned to the pool, and a setup() each
>> time an Atom instance is pulled out of the pool.
>>
>> The result of all this is that the maximum number of Atom instances
>> that are ever created is equal to the maximum number that are in use
>> at any one time, rather than the sum of all instances that were ever
>> in use.  If there is a significant difference between these two
>> figures, pooling might be worthwhile.
>>
>> Of course, the above assumes that the root of the problem is that IE
>> fails to garbage collect disposed instances efficiently.  I did some
>> intensive testing of this a couple of years back and found that IE6 in
>> particular had very unreliable garbage collection within the context
>> of a single, long running page (i.e., when the browser is never asked
>> to reload the page).
>>
>> Cheers,
>>
>> Simon
>>
>>
>>
>>
>> On Fri, Jul 4, 2008 at 1:13 AM, Jim Hunter <[hidden email]> wrote:
>> > So how do you handle the scenario where one tool might have 20 Atoms on
>> > it,
>> > but the next iteration of that tool will have 1000? Do you simply just
>> > add
>> > new controls to the pool if needed allowing it to grow to the max size
>> > needed? Then when they are no longer needed, just set the parent to
>> > null? If
>> > I can't get what I am working on to solve the problem, I will look into
>> > your
>> > solution.
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> > On Wed, Jul 2, 2008 at 11:28 PM, Simon Bull <[hidden email]> wrote:
>> >>
>> >> Hi Jim,
>> >>
>> >> I am not sure which version of qx you are using, but I experienced a
>> >> very similar problem a long while back with qx 0.6.x.  My final
>> >> solution was to implement object pooling, and reuse pooled instances
>> >> rather than instantiating new ones all the time.  I added my Pool
>> >> class to the contribute project, and (from memory -- must have been a
>> >> year ago now) I think Fabian migrated it to qx 0.7.x.
>> >>
>> >> Simon
>> >>
>> >>
>> >>
>> >> On Thu, Jul 3, 2008 at 10:52 AM, Jim Hunter <[hidden email]>
>> >> wrote:
>> >> > I am running into a troubling situation and am looking for a little
>> >> > help. My
>> >> > application re-uses 'tool windows' to display new information. It
>> >> > does
>> >> > so by
>> >> > removing all children (using a function I wrote to iterate through
>> >> > all
>> >> > children, destroy them (they iterate their children before destroying
>> >> > themselves). Then it destroys itself. Then I add the new contents to
>> >> > the
>> >> > tool window. In FireFox (all versions) I have no problems and the
>> >> > page
>> >> > renders in the same amount of time every time I bring it up. In IE
>> >> > (all
>> >> > versions 6-8), it takes longer and longer to render each time I bring
>> >> > up
>> >> > the
>> >> > tool window (I am using a qx.ui.layout.DockLayout as the main body of
>> >> > the
>> >> > tool window). And when I say longer, it goes from 2 seconds to 5
>> >> > seconds
>> >> > to
>> >> > 9 seconds to 15 seconds to 25 seconds etc. It gets out of control
>> >> > very
>> >> > quickly.
>> >> > Has anyone come up with a way to manage this or even eliminate the
>> >> > problem?
>> >> > To me, it looks like the objects are not getting destroyed in memory
>> >> > and
>> >> > it's causing IE to start choking on them and doesn't release them as
>> >> > it
>> >> > should.
>> >> > Here is the function I use to clean out the tool before I add more
>> >> > objects
>> >> > to it:
>> >> >
>> >> > disposeChildren:function()
>> >> > {
>> >> >     try{if(typeof this.hasChildren!='undefined')
>> >> >     {
>> >> >         if(this.hasChildren()==true)
>> >> >         {
>> >> >             this.forEachChild(function(chld)
>> >> >             {
>> >> >                 chld.disposeChildren();
>> >> >                 chld.setParent(null);
>> >> >                 chld.dispose();
>> >> >                 qx.ui.core.Widget.flushGlobalQueues();
>> >> >             });
>> >> >         }
>> >> >     }}
>> >> >     catch(e)
>> >> >     {
>> >> >         try{this.setParent(null);
>> >> >             this.dispose();
>> >> >         }
>> >> >         catch(e){}
>> >> >     }
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > Any assistance would be greatly appreciated as we absolutely need to
>> >> > have IE
>> >> > working somewhat like FireFox. i know it's not going to work as fast,
>> >> > but we
>> >> > do need it to be consistant.
>> >> >
>> >> > Thanks,
>> >> > Jim
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > -------------------------------------------------------------------------
>> >> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> >> > Studies have shown that voting for your favorite open source project,
>> >> > along with a healthy diet, reduces your potential for chronic
>> >> > lameness
>> >> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> >> > _______________________________________________
>> >> > qooxdoo-devel mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> >> >
>> >> >
>> >>
>> >>
>> >> -------------------------------------------------------------------------
>> >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> >> Studies have shown that voting for your favorite open source project,
>> >> along with a healthy diet, reduces your potential for chronic lameness
>> >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> >> _______________________________________________
>> >> 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
>> >
>> > -------------------------------------------------------------------------
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> > _______________________________________________
>> > qooxdoo-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> 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
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel