Re: [gwt-contrib] JavaScript Memory Consumption

[Joel Webber]

Memory leak issues like this is one of the many reasons we ended up building GWT in the first place. It's possible to characterize exactly which constructs do and do not cause leaks, but it's really tricky to maintain real code without causing them accidentally. And as you probably noticed, when you leak one object you tend to leak many of them because they all reference one-another.

GWT avoids this issue altogether by enforcing a (fairly) strict mechanism for event handling at the Widget/Element boundary. If you actually look at the way new Widgets are created, you may wonder why events are a little weird -- it is precisely because of this issue. The end result is that you *cannot* leak memory in GWT without trying extra-hard. The only way you can do so is to write your own javascript event handlers directly in JSNI, which directly or indirectly reference java objects (please don't do this!)

On a side note, getters and setters are one of the most clearly and easily inline-able constructs in Java, and our code generation does get rid of them entirely in some cases. This sort of optimization will be extended even further in the future, so feel free to write your code the way it makes the most sense, and let the compiler do the hard part!

joel.

On 1/19/07, jonke...@gmail.com <jonke...@gmail.com > wrote:

Once upon a time, I was working on a Tetris Dashboard Widget for Mac OS
X. Following a couple suggestions I found online about "extending"
JavaScript objects, I ended up creating getters and setters for a lot
of properties. I continued this method throughout the project even
though I sort of wished I didn't. I started learning my lesson near the
end when the game was running slower than I had imagined possible.

Using an option in Safari's debug menu, I noticed that the number of
allocated objects in memory was around the 80,000 mark or so. It didn't
take to long to figure out that every time a reference (or object, or
whatever JavaScript does) is passed around, that number went up.

For some reason, that number didn't seem to come down very quickly
either, and it would just grow and grow and grow. My solution
eventually led to around 100 new objects allocated per new Tetris piece
instead of several thousand!!! woah!!! In the end, I never really
topped 4,000 total objects in memory (and that number started around
1,500). Those numbers may be a LITTLE off, but the difference is so
significant, I didn't think it's matter to be right on.

Simply removing the getters and setters was enough to bring the number
of objects in memory down substantially. Another big improvement came
from removing some stupid functions I was using from a code snippet
online that actually created the getters and setters for me, which I
remember attributing to another memory allocation every time I used a
getter or setter (that was a minimum of 3 just by calling a get, since
1 was the object itself!).

Anyway, I deleted the whole thing and started over just for fun. This
time ignoring all the online suggestions, it ran smooth as silk when I
was finished. (Actually I never really FINISHED the game, but it does
work. I usually get bored near the end, quit, and invent some other
idea to waste time on--so no Tetris Dashboard widget yet).

By accessing variables in objects directly instead of through getters
and setters improved performance immensely, and there were definitely a
couple other things too. If I ever get the time, I may look for those
sites I found (highly popular Google search results by the way) and
blog them to death because of all the frustration they caused me.

Getters and setters in Java are different, but I believe GWT compiles
them into JavaScript functions just the same. Could the compiler just
not create those functions when appropriate?

I am confident that it would increase performance in the case where a
large program was written like Tetris, but I'm not sure. If anything,
it would cut back on the amount of JavaScript generated.