Thursday, January 30, 2014

Re: GWT dev mode memory leak with simple use case

OK, that's clear. This simple use case does not leak per the JavaScript profiler in Chrome (note to future readers to compile with at least Output style: Pretty). I was originally tracking down a leak in my own code, but it turns out that doesn't leak in JS either.

I suppose that in super dev mode you wouldn't be dealing with this, because you'd be using your debugger and profiler strictly in JS.

Thanks for the response.

On Thursday, January 30, 2014 1:33:19 PM UTC+1, Jens wrote:

But even if you find memory leaks in Java it does not mean that its a JavaScript memory leak. Also you might have a JavaScript leak thats not a Java leak. So at the end you want to compile your app and use chrome dev tools to look for memory leaks. One memory leak that is very easy to spot in chrome dev tools are "detached DOM trees". These are DOM trees that are still referenced by JavaScript code although they are not attached to the document. If you see large numbers of them then it is likely that you clear() some widgets somewhere but JS still has a reference to them.
But be aware that not all detached DOM trees are memory leaks. If you have a widget / DOM element that you only insert into the DOM on certain conditions and otherwise is held in memory then its probably fine (e.g. show either this or that view but both views are already created and held in memory).

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

No comments:

Post a Comment