jasonharper
Developer
That's a lot of work for little benefit: most of the buffbot-related junk I found in the heap dump was related to the UI components, not the XML data itself.
Memory leaks?
- Thread starter greenrider
- Start date
Then why are the UI components not being marked for garbage collection?! That's the problem. Keep whatever you want from the XML files if you insist, but if it's the UI then the memory should be freed once the window is closed.
holatuwol
Developer
Unless something has changed in the two years since I last worked on the project, most of the windows in KoLmafia don't get closed (they get hidden).
The benefit of doing things this way is that it allows those windows to reload faster if people ever need to reopen them, which (at the time) was much more common than loading them once per session.
greenrider
Member
I can see the reasoning behind that design choice. However, you're talking something like 10-15% of the total memory space allocated to mafia now being permanently used by a window that many people use just once per session.
In any case, I think the root cause of the slowdown is probably not the buff window, since I know I've experienced the worst issues on days when I never opened that particular window at all. But perhaps this is indicative of some of the reasons why mafia burns through memory so quickly?
Bale
Minion
It wouldn't seem unreasonable for some windows to be treated differently than others. The buff window is pretty much the only one I can think of that is used basically once, though perhaps that is different for other people... More information is needed before making such a decisionl.
greenrider
Member
It also begs the question of why it's suddenly in vogue to misuse 'begs the question' in various KoL forums
http://forums.kingdomofloathing.com/vb/showpost.php?p=2761888&postcount=20
But yeah, it does seem like a lot of memory for one window. Are there any nifty memory-tracing tools for Java that might be helpful in mapping out stray objects that should be getting cleaned up? Or is this definitely a design-choice kind of thing?
In my unscientific tests, I noticed about a 2.5-3.0 second delay to open the buff window upon a fresh start of mafia. Subsequent openings are instant, thanks to the caching mentioned above. 3 seconds is obviously not an ideal response time for a UI element, but given the relatively few number of times you would want to open that window multiple times per session, that might actually be preferable to burning 10-12MB out of 64.
holatuwol
Developer
After Jason's improvements, it's only using 5-6 MB on my system. Is it still using 12 MB on your system?
It also begs the question of why it's suddenly in vogue to misuse 'begs the question' in various KoL forums
Haha, yeah I guess I never really thought about context, see also.
This has always been the behavior. No new cache method has been implemented.
Yes, you can use jmap to dump the memory and then jhat to interpret the dump. It can be a bit overwhelming though, especially if you're not familiar with the components of the project.
Tested in r7643. Noticed the memory did jump up by 12mb once the GUI had fully loaded. Tested again in r7647 and it used only 6mb of RAM (nice improvement).
The behavior still seems a bit odd though. If I open mafia and let it run for about a minute to settle then force garbage collection, it will be using roughly 30mb of RAM, +/-2mb. If I then open the Item Manager, that will increase by around 3mb. Now if I close the item manager, wait a few moments and force garbage collection, about 2mb will be freed.
Now if I open Purchase Buffs, the memory will go up by about 6mb, however, if I close the Purchase Buff UI, wait a few moments, then force garbage collection, only about 500k will be freed.
So what's with the higher memory usage? Is it the XML file data being kept in memory? Or is it something funky in the UI that uses more memory than the Item Manager?
The extra 6-7mb free from the improvements can go a long way, but I still think something is a bit funny with the buff purchasing window.
holatuwol
Developer
It's something funky in the way the UI was implemented.
jasonharper
Developer
The Purchase Buffs window creates a LOT more UI components than the Item Manager - each individual buff offering from each buffbot becomes a separate checkbox, while the Item Manager panels are basically a list (the individual items of which are not separate components) and a few buttons. Previously, ALL of the buff checkboxes specified their text in HTML format, whether they actually needed any special formatting or not, and that creates more overhead than you'd guess - Swing's support for HTML is in the form of a full-blown HTML editor component, any static use of HTML is actually an editor in read-only mode. What caught my eye in the heap dump were 573 instances of an 8 kilobyte edit buffer, most of which were associated with one of the buff checkboxes.
The checkboxes for buff packs can't easily be un-HTMLed (Swing provides no other way of having a checkbox with a multi-line label), but the individual buffs can (and were).
The checkboxes for buff packs can't easily be un-HTMLed (Swing provides no other way of having a checkbox with a multi-line label), but the individual buffs can (and were).
Hmm, well thanks for the explanation. You can see that the problem will worsen if people add more buffbots. I guess the best way around it for the hardcore KoLmafians would be for them to either implement their daily buff requests in a simple ASH script, or restart KoL if they want to free up that extra bit of memory.
This problem was never actually an issue for me, because I typically only run Mafia for an hour or so each day anyway. Either way I'm glad to see some improvements have been made
This problem was never actually an issue for me, because I typically only run Mafia for an hour or so each day anyway. Either way I'm glad to see some improvements have been made