Hi Andreas,
Thanks for your reply.
> I'd like to stress one important fact: one gets easily fooled in this
> area, because of observations that seem reasonable or plausible. The
It is true -- memory freeing behaviour is difficult to quantify. However, in
the absence of all other information we must fall back on observations. What
we conclude from those observations is the tricky part. However, so far I have
seen no evidence that suggests IE6 definately cannot free memory without a page
reload. On the contrary -- for POJOs and some Qx objects it does.
> Albeit annoying, there is nothing wrong about the memory _creep_
There is nothing wrong with memory allocation. It is memory that is not freed
after the object is removed/disposed which is a problem for me. I have a live
production app in which memory creep crashes the browser -- this is more than
just annoying, it is the single most critical issue on the project.
> (or install IE7?)
That would be nice. However, we have with a government user base and IE6 is
the specified operational environment. That is not likley to change any time
soon.
A useful test will be to run my test case on some other browsers (including
IE7) and compare the results to IE6. That should give some indication as to
what proportion of the observed memory creep is attributable to the JS code and
to the browser's GC behaviour.
I will try this soon and report my observations.
Simon
Hi Simon,
just wanted to say thanks for your ongoing effort of analyzing and
measuring memory creep (or maybe leak) issues in qooxdoo. :-)
We should definitely put some concise information about memory
creep/leak into the wiki. Garbage collection in general is non-trivial.
The closed-source/undocumented GC implementations make it even harder to
understand the behavior of each JS runtime environment (a.k.a. "web
browser").
I'd like to stress one important fact: one gets easily fooled in this
area, because of observations that seem reasonable or plausible. The
nature of GC implementations and their unknown "triggers" to actually
free memory can lead to some misconception and wrong quantitative analysis.
For example, to take away substantial amount of functionality and code
from qooxdoo widgets certainly does reduce their memory footprint.
Despite being reasonable, this does not necessarily mean that the
removed functionality is the origin of any memory problems.
Albeit annoying, there is nothing wrong about the memory _creep_
behavior, as it is without reach for JavaScript applications to manually
_free_ previously used memory. It is the GC's job to do the actual
memory management. What can be done is to completely dispose all
relevant objects (i.e. removal of references, etc.) which is exactly
what qooxdoo does. Maybe some dispose methods of qooxdoo widgets are
still incomplete or buggy. These cases should be identifiyed and fixed
asap. In principle qooxdoo is (supposed to be) free of memory leaks.
Sorry folks, my lawyer had me to insert the text in parentheses. ;-)
There may be smart ways to programatically trigger certain GCs to free
memory. But it is hard to think of any general (even working) solutions
given the lack of control. There are some hardly known heuristics and
facts about browser like IE6. For example, there are fixed total numbers
of either strings, arrays or objects that trigger the IE6 GC. Minimizing
and restoring the IE browser window does free large amounts of memory...
How to cope with the annoying fact of memory creep in large
single-page-applications is an interesting topic that limits today's
size of web applications (particularly for IE6). Advanced solutions like
on-demand JavaScript code, object pooling, smart object disposal, etc.
are becoming more important concepts. Currently, the best solution in
IE6 simply is to avoid object instances (or install IE7?).
It would be great to have more discussion in this area and to get more
qualitative and quantitative feedback from users regarding their
real-life qooxdoo applications (medium- or large-scale).
Bye,
Andreas
Simon Bull wrote:
> Hi again,
>
> Here are some more (interesting?) observations for the "memory creep"
> discussion:
>
>
> IE Does Free Allocated Memory Without Page Reload
> -------------------------------------------------
>
> I have modified my original memory test case so that tested POJOs are
> much bigger. The impact of this is that more memory is allocated to
> each POJO instance -- and all allocated memory is freed when the
> POJOs are removed.
>
> I attribute the small POJO memory creep that I previously observed to
> that fact that the POJO instances I previously tested were so small
> that small variations in browser behaviour had a big impact on
> apparent memory creep.
>
> Increasing the POJO size dramtically meant that the same small
> variations in browser behaviour were no longer significant compared
> to the amount of memory be allocated and freed.
>
>
> Memory Allocation, Free, Creep for TextField
> --------------------------------------------
>
> I decided to look into qx.ui.form.TextField because:
>
> 1) it's a low level widget not composed of other widgets, 2) it was
> observed to have a memory creep -- 48kb allocated, 2kb freed, 46kb
> creep per instance disposed, 3) it has relatively simple source code.
>
>
>
>
> By commenting out sections of the qx.ui.form.TextField sourcecode and
> then running my memory creep test case, I was able to observe how
> much memory was being allocated by specific parts of code, and which
> code allocated memory that was not freed later.
>
> From these observations I was able to attribute the most significant
> portion of observered memory allocation and memory creep to one line
> of code:
>
>
> qx.OO.changeProperty({ name : "appearance"...
>
>
> I also observed some memory creep was associated with:
>
>
> qx.client.Timer.once(this._ieFirstInputFix, this, 1);
>
>
>
> Here is a summary of latest my observations:
>
> allocated freed creep (kb) (kb) (kb) POJO 26.5
> 26.7 -0.2 ( 0%) TextField 46.6 1.6 45.0 (96%)
> TextField* 5.3 2.6 2.7 (51%) TextField**
> 5.2 4.5 0.6 (12%)
>
> * with changeProperty(appearance) commented out. ** with
> changeProperty(appearance) and Timer.once() commented out.
>
>
> From these observations I conclude that:
>
> 1. It is possible for IE6 to free allocated memory without reloading
> the page.
>
> 2. Variations in browser behaviour mean that measured memory figures
> are only estimates: to get more accurate measures I would need to
> automate the tests and run a larger sample sizes.
>
> 3. Most (~90%) of the memory allocated to a TextField is used by its
> "appearance" code -- and most of this memory is not freed after
> dispose().
>
> 4. Timer appears to use ~2kb of memory that is not freed after
> dispose().
>
>
>
> So I will now try to explicitly "unset"/remove a widget's appearance
> in its dispose method, but I couldn't see a nice way to do this.
>
> Does anyone have any ideas that I could look into for cleaning up a
> widget's appearance? Does the code already try to do this somewhere?
>
>
>
>
> Thanks,
>
> Simon
____________________________________________________
Do you Yahoo!?
Yahoo!7 Time Capsule - Make your mark and be a part of history
http://www.yahoo7.com.au/timecapsule
-------------------------------------------------------------------------
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
