Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 244976 - Reduce Browser Memory Consumption
Summary: Reduce Browser Memory Consumption
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.1.2   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 257022
Blocks:
  Show dependency tree
 
Reported: 2008-08-22 12:04 EDT by Stefan Hansel CLA
Modified: 2009-02-19 05:27 EST (History)
2 users (show)

See Also:


Attachments
simple qooxdoo application to test for memory leaks (1.36 KB, text/plain)
2008-08-22 12:04 EDT, Stefan Hansel CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Hansel CLA 2008-08-22 12:04:18 EDT
Created attachment 110698 [details]
simple qooxdoo application to test for memory leaks

I was finally able to create a 0.7.x-qooxdoo application that almost doesn't leak any memory when using simple widgets, see following thread in qooxdoo newsgroup: 
http://thread.gmane.org/gmane.comp.lang.javascript.qooxdoo.devel/16253

As I saw you already manually call widget.setParent(null) in your WidgetManager - so actually you don't need to wait for their reaction.
Anyway - in the current qooxdoo 0.7.x-branch there are further fixes after 0.7.3, which correctly clear other references to disposed widgets.
Only with these fixes the browser will release aquired memory.


So I think you either have to switch to current 0.7.x-branch or backport some of the changes (mainly the classes I mentioned in the qooxdoo thread).

If you just backport fixes, furthermore you might manually need to call widget.disconnect() before disposal, I think it's not called otherwise.

Unfortunately (due to holidays and an angry wife ;-)) I don't have much time to test with RAP as well, but I have a very good feeling, that this could solve the big memory problems in IE.

As I don't know whether you have to backport stuff or just can use the current 0.7.x-branch I didn't spend time to analyze if other changes since 0.7.3 than the mentioned need a backport too.

Attached you will find my little qooxdoo-testapp for 0.7.x where you can see quite easy if qooxdoo leaks (by watching the taskmanager) in whatever version used.
Comment 1 Ralf Sternberg CLA 2008-08-23 05:38:33 EDT
Hi Stefan,

first of all, many thanks for your investigation of the memory leaks in qooxdoo, your results are most appreciated.

From your description I think it makes sense to switch to a newer version of the 0.7.x branch soon. But as we need to have every adopted qx version IP-approved, this can take quite a while anyway. Moreover, it's sometimes not easy to distinguish a stable version in the qx trunk, since the qx team commits without testing. We have to check if they plan to provide a 0.7.4 release soon. If so, we should perhaps wait for that.

If the critical fixes are rather small and isolated, backporting should be easily done. Patches against 0.7.3 are welcome (and you probably know best what needs to be changed), but if you don't have the time now, we will try to create those patches from the current versions of the classes mentioned in your thread on the qx-list and we will also add the widget.disconnect() call before widget.dispose().
Comment 2 Stefan Hansel CLA 2008-08-27 12:23:40 EDT
From my gut-feeling I'd say that qooxdoo 0.7.4 will be out only in one or two months. 
Quoted from Sebastian Werner: 'We [...] plan to release a 0.7.4 some time after 0.8 is out. It's just that 0.8 has the focus at the moment.'
So this would be to olate for RAP 1.1.1-release I suppose.

0.7.4 will have the best memory-behaviour as there are still some open discussions about creating a 'destroy' method, with some more tweaks.
If you can provide a RAP 1.1.2-release by then this would be all our company needed. But waiting for July 2009 and RAP 1.2 is not an option for us ;-) ...

Anyway - all the fixes done already on the branch make a huuuuge difference in memory consumption (even now and even if investigations are not completed yet). 
So if you already want to have a big effect in 1.1.1 for all other users that can't wait any longer, it makes much sense to backport the current changes.

As I wrote - I don't expect too much work - qx.util.manager.Value was rewritten to support unregistering classes, the mixin qx.util.manager.MConnectedObject was added, so that every widget also uses this new ability to disconnect.

I'm sorry, but I wont be able to put more work on this in the next two weeks or so. After that I could create a patch if this then could still be included in 1.1.1.

Within the next 2 weeks I'll still be able to answer questions and help of course.
Comment 3 Ralf Sternberg CLA 2008-08-29 16:14:16 EDT
Sure qx 0.7.4 will definitely come too late for 1.1.1. Nevertheless, we consider adopting qx 0.7.4 when it is out. If there is a qx version or a patch available, that brings a significant improvement of the browser memory consumption and can be easily backported to RAP 1.1, then you won't have to wait until next summer.

Unfortunately, we have tons of work and reduced capacity in the next couple of weeks, so we won't have much time for investigating this issue now. If you could provide a patch after this two weeks, this would be a great help. The release date for 1.1.1 is not finally agreed upon, chances are that this patch still makes it into 1.1.1. If not, I think this could even justify a 1.1.2.
Comment 4 Stefan Hansel CLA 2008-09-01 12:12:15 EDT
>> If not, I think this could even justify a 1.1.2.

If that holds true, I'd rather use my time, to push the qooxdoo team to a good near-leak-free 2.7.4 release. As I said there are still some open issues in the branch-head, which could be fixed with not too much work.

As most of the qooxdoo-team is on holiday next month, I'll stay a bit quiet - suppose I stressed them already quite much. 

As there are 4 month to go this year - two for the qooxdoo team, two for the RAP-team - I hope it's quite realistic to expect a 1.1.2 version by the end of the year ?
Comment 5 Frank Appel CLA 2008-09-02 04:31:40 EDT
To avoid misunderstandings I want to say that the RAP service releases are in general bound to the Ganymede release plan: http://wiki.eclipse.org/Ganymede#Coordinated_Service_Releases. So SR2 is expected in February. The only margin for the schedule that we have is with respect to the staging.

That doesn't mean that we are not able to produce some intermediate builds that fix problems of huge interests like the memory consumption. So we do really appreciate your commitment on this and it seems that you're more successful on getting through to the qooxdoo team with respect to the memory consumption than we were in the past. So if you need any assistance or help on this feel free to nag us.
Comment 6 Ralf Sternberg CLA 2008-12-15 15:26:58 EST
With the adoption of qooxdoo 0.7.4, and a small change in the WidgetManager.js (calling destroy instead of dispose to dispose of widgets), it seems that there is only a minor leak in the tree remaining.
Comment 7 Stefan Hansel CLA 2009-01-23 08:12:16 EST
Is it still true, that qx7.4 will be integrated into 1.1.SR2 ?
Comment 8 Rüdiger Herrmann CLA 2009-01-23 09:16:30 EST
(In reply to comment #7)
> Is it still true, that qx7.4 will be integrated into 1.1.SR2 ?
yes
Comment 9 Ralf Sternberg CLA 2009-02-19 05:27:09 EST
The 1.1.2 service release is available at http://www.eclipse.org/rap/downloads/
This release contains qooxdoo 0.7.4 including the memory consumption improvements.