So I will summarize my knowledge regarding this issue. While I agree it is a bit shallow it is much better than nothing at all.
Tools like IESieve and IEdrip proven to be inefficient when coming to GWT leaks the code is too big for them and the transformation from Java to JS complicates things.
I will be more that delighted to be proven an idiot, if someone have a better (proven) approach please let me know.
When coming to solve /prevent memory leaks the best way will always be code review. Hence I will give a list of guidelines for reviewing GWT code:
First list of guidelines Stating the obvious:
- Avoid writing JSNI code. Google made quite a good job in writing "almost" leak free it is so easy to ruin it if you do not know what you are doing. Remember every JSNI code you write will lower your productivity.
- Do not use the DOM.* methods (except the setStyle... which are safe) . Manipulating the DOM yourself will lead you directly toward a memory leak.
- Static variables containing(even indirectly) references to widgets and dom objects may cause a leak.
- According to Google it should not happen :-) but in some cases event listeners may leak. unregistered them when window unloads.
Lion in the desert approach
Saying that all you need to do is comment out pieces of code until memory leak is eliminated.
This process is not easy nor fun some tips to improve its effectiveness:
- Memory leaks are ilusive sometimes removing an irellevant piece of code will stop the memroy leak. As a result you should try to reach to the smallest peice of code which is still leaking before eliminating it. This will ensure you do not shoot at the wrong target .
Thats all folks :-)
Post a Comment