Hi Sebastian,
Thanks for your replies to my various memory posts. I only use the term "memory leak" because it is familiar to people, let's use the term "memory creep" if you prefer. I do realise that many widgets are composed of others. However, I thought it may be worthwhile to know that if (for example) widget X was observed to creep 5kb per instance, and widget Y (which was composed of 2 instances of X) was observed to creep 10kb per instance, then we might conclude that the creep of Y was entirely attributable to the creep of X -- and therefore not go looking into the source code of Y for the problem. So I didn't test all those widgets to compare them to one another. I tested them all to identify places where debugging effort might best be spent. I also understand well that js code has no direct control over memory management in the browser -- I have done quite a bit of testing in this area. Now that I know (from your previous reply) that dispose() is not intended to make memory available for garbage collection I'll stop trying to figure out why it doesn't. However -- given that my recent tests show that some widgets have virtually no memory creep problem, it seems a reasonable assumption that all widgets could be memory creep free too. Do you agree? Simon ----- Original Message ---- From: Sebastian Werner <[EMAIL PROTECTED]> To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net> Sent: Tuesday, 17 October, 2006 7:15:12 PM Subject: Re: [qooxdoo-devel] Memory use test results for Qx 0.6.2 (r4314) on Win2k IE6 Hi Simon, thank you for your work. It seems like you have invested many hours. However in my opinion it is not a good option to name this problem, if it really is one, a "leak". As explained in my previous answer a leak is when you reproduce able have a memory problem while leaving and reopening the page. It's already well known that the garbage collector of IE6 only really freed memory, when you leave the current page or minimize the browser window. Without the current disposers it would mean that the memory usage of IE dramatically increases between simple reload situations e.g. entering and leaving the page multiple times. Another thing one must know is that many of the complex widgets you tested are built using other smaller widgets. So the most qooxdoo objects internally create other objects/widgets. It's not really helpful in my opinion to compare Terminator with Button etc. because a Button itself consists of multiple Terminators. One interesting thing for example is that when you create a large array the only possibility to directly cleanup the memory is to shrink the array first and than delete it. In my opinion this can result in to much CPU usage just for disposing stuff. Maybe there are other people on the list with ideas to help in these situations, but as explained before a pooling is one of the good ones to get it done right. Regards, Sebastian Simon Bull schrieb: > Hi All, > > I've built a simple Qx test case (see attached) that creates and disposes n > many instances of a selected widget type. > > This test enables us to observe how much memory is allocated by new() and > freed by dispose() for each widget type. I've used this test to quantify > memory usage of most of the qx.ui.* widgets. If the results might interest > you, read on... > > > > Quick Summary > ============= > > Plain old javascript Object and 38 Qx widgets of the qx.ui.* package were > tested for memory leaks in IE6 by creating and disposing 100 instances and > recording differences in the browser's memory footprint. This was repeated > twenty times in a row for each class. > > Plain old javascript Object instances leaked 0.27kb per instance -- this was > considered the baseline for comparison. > > 12 widget classes leaked between 1 and 10kb per instance. > > 15 widget classes leaked between 27 and 54kb per instance. > > 6 widget classes leaked between 125 and 145kb per instance. > > 5 widget classes were disregarded because messages written to the qx logging > console during testing skewed the results. > > > > > Test Method > =========== > > My test environment is: > > Windows2000, > IE6.0.2800.1106CO, > Qx 0.6.2 r4314. > > I monitor IE's memory use with: > http://www.sysinternals.com/Utilities/ProcessExplorer.html > > My test case is as follows: > > 1) Load the test page (see attached), > 2) Select a widget type from the drop down list, > 3) Record the IE process's memory size, > 4) Click the "create" button (which creates 100 instances of the widget type), > 5) Record the IE process's memory size, > 6) click the "dispose" button (which disposes all created widgets), > 7) Record the IE process's memory size, > 8) Repeat step 4) to 7) twenty times for each widget type. > > Some things I noticed: > > 1) Any deviation from the test case (above) that fires any browser event can > trigger a browser reponse that allocates memory, and therefore invalidates > the test result. > > 2) Even when the test case is followed exactly browser memory > allocation/release is variable. Invoking the same action several times in a > row has a different impact on the browser's memory footprint each time. In > particular, the first repeat of the test case always appears to allocate a > lot more memory than later repeats. Using 20 repeats appeared to be enough > to smooth out this variability and get a reliable measure. > > 3) ProcessExplorer always reports the browser's memory footprint as a factor > of 2kb. It is not obvious why this should be the case. > > 4) Messages written to the qx logging console caused the browser to allocate > memory. > > > > Observations for POJO > ===================== > > Before testing any Qx classes I tested the "plain old javascript Object" > class. > > For the baseline test case I created 1,000 (rather than 100) instances of > Object. Each instance has 26 very long (and unique) Strings added to it as > properties. The test then removes each instance and its properties from > memory. This baseline testcase was repeated 20 times. > > Because the amount of memory allocated to each instance is very small, > variability in memory allocation behaviour appears to exaggerate the actual > memory changes on a per instance basis. Because of this I created 10 times > as many instances for the baseline testcase. > > Across 20,000 Object instances created and removed, I observed a mean memory > leak of 0.27kb per Object instance. > > I consider this the "baseline". > > > > Observations for Qx Classes > =========================== > > Here is a summary of my observations. > > The "%" figure is the percent of total memory allocated by new() that is not > freed after dispose(). > > The "kb" figure is the mean memory leak per instance of the widget type. > > The "8x pojo" figure is the kb figure expressed as a factor of baseline > object memory leak. > > > > Results sorted by least leaky widget by % of allocated memory not freed: > > 1%, 0kb, 1x pojo -- Plain Old JS Object (20,000 instances) > 1%, 1kb, 7x pojo -- qx.ui.basic.Terminator > 1%, 2kb, 7x pojo -- qx.ui.form.InputCheckSymbol > 1%, 2kb, 10x pojo -- qx.ui.basic.Label > 5%, 5kb, 23x pojo -- qx.ui.core.ScrollBar > 5%, 5kb, 23x pojo -- qx.ui.form.CheckBox > 5%, 5kb, 24x pojo -- qx.ui.form.RadioButton > 5%, 6kb, 27x pojo -- qx.ui.form.ListItem > 5%, 6kb, 28x pojo -- qx.ui.tree.TreeFile > 5%, 6kb, 29x pojo -- qx.ui.basic.Atom > 5%, 9kb, 46x pojo -- qx.ui.tree.Tree > 6%, 6kb, 32x pojo -- qx.ui.tree.TreeFolder > 42%, 52kb, 255x pojo -- qx.ui.toolbar.ToolBarButton > 44%, 28kb, 137x pojo -- qx.ui.toolbar.ToolBarPart > 50%, 52kb, 257x pojo -- qx.ui.toolbar.ToolBarCheckBox > 51%, 52kb, 256x pojo -- qx.ui.toolbar.ToolBarRadioButton > 56%, 53kb, 262x pojo -- qx.ui.form.Button > 56%, 54kb, 266x pojo -- qx.ui.form.RepeatButton > 67%, 2kb, 9x pojo -- qx.ui.menu.MenuLayout > 74%, 125kb, 613x pojo -- qx.ui.menu.MenuBarButton > 78%, 50kb, 247x pojo -- qx.ui.toolbar.ToolBarMenuButton > 84%, 136kb, 670x pojo -- qx.ui.form.ComboBox > 86%, 146kb, 715x pojo -- qx.ui.form.Spinner > 90%, 144kb, 709x pojo -- qx.ui.groupbox.GroupBox > 95%, 27kb, 133x pojo -- qx.ui.toolbar.ToolBarPartHandle > 96%, 46kb, 227x pojo -- qx.ui.form.TextField > 96%, 46kb, 228x pojo -- qx.ui.form.TextArea > 96%, 47kb, 229x pojo -- qx.ui.form.PasswordField > 102%, 39kb, 189x pojo -- qx.ui.menu.Menu > 108%, 145kb, 715x pojo -- qx.ui.groupbox.CheckGroupBox > 109%, 145kb, 714x pojo -- qx.ui.groupbox.RadioGroupBox > 159%, 44kb, 215x pojo -- qx.ui.toolbar.ToolBar > 159%, 2kb, 217x pojo -- qx.ui.form.List > 165%, 44kb, 215x pojo -- qx.ui.menu.MenuBar > > > > Results sorted by least leaky widget by kb leaked per disposed instance: > > 0kb, 1%, 1x pojo -- Plain Old JS Object (20,000 instances) > 1kb, 1%, 7x pojo -- qx.ui.basic.Terminator > 2kb, 1%, 7x pojo -- qx.ui.form.InputCheckSymbol > 2kb, 67%, 9x pojo -- qx.ui.menu.MenuLayout > 2kb, 1%, 10x pojo -- qx.ui.basic.Label > 5kb, 5%, 23x pojo -- qx.ui.core.ScrollBar > 5kb, 5%, 23x pojo -- qx.ui.form.CheckBox > 5kb, 5%, 24x pojo -- qx.ui.form.RadioButton > 6kb, 5%, 27x pojo -- qx.ui.form.ListItem > 6kb, 5%, 28x pojo -- qx.ui.tree.TreeFile > 6kb, 5%, 29x pojo -- qx.ui.basic.Atom > 6kb, 6%, 32x pojo -- qx.ui.tree.TreeFolder > 9kb, 5%, 46x pojo -- qx.ui.tree.Tree > 27kb, 95%, 133x pojo -- qx.ui.toolbar.ToolBarPartHandle > 28kb, 44%, 137x pojo -- qx.ui.toolbar.ToolBarPart > 39kb, 102%, 189x pojo -- qx.ui.menu.Menu > 44kb, 159%, 215x pojo -- qx.ui.toolbar.ToolBar > 44kb, 165%, 215x pojo -- qx.ui.menu.MenuBar > 2kb, 159%, 217x pojo -- qx.ui.form.List > 46kb, 96%, 227x pojo -- qx.ui.form.TextField > 46kb, 96%, 228x pojo -- qx.ui.form.TextArea > 47kb, 96%, 229x pojo -- qx.ui.form.PasswordField > 50kb, 78%, 247x pojo -- qx.ui.toolbar.ToolBarMenuButton > 52kb, 42%, 255x pojo -- qx.ui.toolbar.ToolBarButton > 52kb, 51%, 256x pojo -- qx.ui.toolbar.ToolBarRadioButton > 52kb, 50%, 257x pojo -- qx.ui.toolbar.ToolBarCheckBox > 53kb, 56%, 262x pojo -- qx.ui.form.Button > 54kb, 56%, 266x pojo -- qx.ui.form.RepeatButton > 125kb, 74%, 613x pojo -- qx.ui.menu.MenuBarButton > 136kb, 84%, 670x pojo -- qx.ui.form.ComboBox > 144kb, 90%, 709x pojo -- qx.ui.groupbox.GroupBox > 145kb, 109%, 714x pojo -- qx.ui.groupbox.RadioGroupBox > 146kb, 86%, 715x pojo -- qx.ui.form.Spinner > 145kb, 108%, 715x pojo -- qx.ui.groupbox.CheckGroupBox > > > > Measurements for qx.ui.menu.MenuButton, qx.ui.menu.MenuCheckBox, > qx.ui.menu.MenuRadioButton, qx.ui.menu.MenuSeperator, and > qx.ui.toolbar.ToolBarRadioSeperator had to be disregarded because messages > written to the console caused the browser to allocate memory unrelated to the > test case. > > > > Summary > ======= > > Across 33 Qx widgets types tested successfully only 12 appeared to be > more-or-less leakfree. 15 widget classes leaked between 27 and 54kb per > instance. The 6 worst performing widget classes leaked between 125 and 145kb > per instance -- which was more than they were originally allocated. For > these 6 types, dispose actually consumed memory rather than freeing it. > > 5 widget classes were disregarded because messages written to the qx logging > console during testing skewed the results. > > Across the entire test suite, every instance created and disposed leaked an > average of 46kb. > > This implies that 46Mb of memory is leaked per 1,000 widget instances > disposed, and that 460Mb of memory is leaked per 10,000 widget instances > disposed. > > However -- I also observed that the first few repeats of each test case > consumed much more than the average amount of memory. Typically 2 to 3 times > as much, but in some cases up to 20 times as much. Applications that don't > create thousands of widget instances will probably observe this much more > voracious memory usage pattern. > > > > Cheers, > > > Simon > > > > p.s. If you are interested in the *painstakingly collected* raw data I'll be > happy to post them (currently in Excel spreadsheet form). > > > > > > > > > > > > > > ____________________________________________________ > On Yahoo!7 > Men's Health: What music do you want to hear on Men's Health Radio? > http://www.menshealthmagazine.com.au/ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ------------------------------------------------------------------------ > > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ____________________________________________________ On Yahoo!7 Break a world record with Total Girl's World’s Largest Slumber Party http://www.totalgirl.com.au/slumberparty ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
