Extreme slowdowns and memory usage

[Doublestrike]

As promised, here's a few initial screenshots from 4 heap dumps over about 25 minutes of play (20:13, 20:22, 20:34, 20:38). The largest slowdowns were happening at 20:34 (heapdump834.png).

The majority of the memory is "leaked" in the preloader for each one.

Looks like there's a problem with the text fields in ViewTabber, which are probably instances of spells on the Magic stack, and the mana labels in the player field pop up in some cases.

These heap dumps were taken from a JVM running inside Eclipse while using the match UI.

Interested to hear if this is valuable to anyone - if so, I can continue posting various results, or I'll bumble around myself until it's figured out.

[slapshot5]

I just checked in some fixes for un-necessary JTextArea instances in ViewTabber. I wouldn't think this would be a problem between matches, but certainly can become a problem if you Continue and Restart (without Quitting) in Constructed mode.

-slapshot5

[Doublestrike]

I've just been dumping and analyzing heaps for the last few hours and there is definitely a problem in ViewTabber, as Slapshot observed and hopefully resolved. There are cases where up to 16 instances of the same spell are dumped into the stack, which obviously piles up quickly. I'll attack again tomorrow night.

However, the analysis also showed that the observers and listeners are apparently all cleared up - the UI starts pretty much fresh each time a match starts. Just the tabber persist problem is eating a fair amount of memory.

Also, there are some thread safety issues with the card animations. I couldn't quickly find a solution that didn't cancel the animations, so these will remain for a while. Later, when I spiff up the UI with a few effects, I can revisit this problem and fix it permanently.

[slapshot5]

I think I found something with the image cache that could explain the difference between 1.1.8 and 1.2.0 especially in quest mode (which seems to be most commonly reported). I'll test tonight and check in. I'm trying to get some numbers to see if this resolves anything. Also trying to tweak a few things with the cache.

-slapshot5

[slapshot5]

I've just been dumping and analyzing heaps for the last few hours and there is definitely a problem in ViewTabber, as Slapshot observed and hopefully resolved. There are cases where up to 16 instances of the same spell are dumped into the stack, which obviously piles up quickly. I'll attack again tomorrow night.

I cleared up some JTextArea things related to GameLog and Combat. Nothing with the Stack. I didn't see anything jump out at me there as being able to be released. Have at it. I'll be looking at ImageCache tonight.

-slapshot5

[silly freak]

I just checked in some fixes for un-necessary JTextArea instances in ViewTabber. I wouldn't think this would be a problem between matches, but certainly can become a problem if you Continue and Restart (without Quitting) in Constructed mode.

-slapshot5

I've just been dumping and analyzing heaps for the last few hours and there is definitely a problem in ViewTabber, as Slapshot observed and hopefully resolved. There are cases where up to 16 instances of the same spell are dumped into the stack, which obviously piles up quickly. I'll attack again tomorrow night.

I cleared up some JTextArea things related to GameLog and Combat. Nothing with the Stack. I didn't see anything jump out at me there as being able to be released. Have at it. I'll be looking at ImageCache tonight.

-slapshot5

I also looked at the dumps and ViewTabber quickly, and before reading your post, it seemed to me that it must be that the FPanels, but not the Lists were cleared in the update method(s). Since the code was commented out in the rev I looked at, I guess that's exactly what you fixed.

Short version: If two of us got the same impression from the research, it can't be that wrong I hope we found it!

[Doublestrike]

I'm pleased to report that my latest round of heap dumps have not shown anything out of the ordinary - no leaks, no memory-intensive operations (besides the usual: preloaded card pictures and graphics processing). This was after a fairly long session, where performance was reasonably quick the whole time. So it will be interesting to see the end user reports!

[Chris H.]

A lot of time and effort have gone into fixing the memory leak problems that were recently noticed and reported to the dev team. Doublestrike and Slapshot deserve our applause and we are very thankful. People should be able to now play long multi match sessions without noticing slow downs and pauses.

We have a new snapshot build for our testers to try out this weekend. We would appreciate any responses from our testers in reference to the old memory leak plus slowdown issues. If things are now better please let us know.

forge-1.2.1-20120113.122344-17.tar.bz2

forge-1.2.1-20120113.122344-17-osx.tar.bz2