I noticed that my game was gobbling up memory like there was no tomorrow, increasing the heap size to up towards 6-700mb at worst. I turned on some profiling to see what was happening, and noticed nifty was creating a tremendous amount of Abstract List objects and HashMap entries.
At this point i looking at a full screen nifty screen with a layer on top of it, showing a couple of images. Nothing in the app(let) is being updated, it’s just rendering the screen.
I don’t know much about what’s going on under the hood of nifty, so i’m looking for a few pointers as to what could be causing this. Surely it can’t be normal? Attaching a few images of the profiler results.
I guess you could say that nifty gui hasn’t been optimized for garbage collection … However if I see the results correctly the AbstractLists and HashMaps only take about 5 MB memory?
Anyways, its possible to avoid generating garbage by simply iterating over the list using a for int loop instead of using an iterator. For the HashMap/HashSet it is possible to create custom optimized classes that do not generate garbage on iteration, jME3 for example has IntMap and ListMap which do not generate garbage, they are used internally for rendering.
As for increasing the heap size, thats what the JVM does automatically unless you limit the heap size. Using -Xmx command.
It is “lazy” when garbage collecting, so it will let garbage pile up until there’s no more space to allocate and then the garbage collector will be invoked.
But there’s a downside to limiting heap size as that means more garbage collection pauses during gameplay, which stutters FPS. It is best if nifty gets optimized instead.
I’m not 100% sure how the profiler works, but it’s set to record every 10 objects, so it might be that they’re actually taking up 50mb. But it seems to be where the action happens, and it seems to be nifty stuff. The other entries are quite constant at that time, and the heap itself is < 100mb during loading/init, and then takes off.
Yes, the current Nifty is not (yet) optimized for garbage collection!
That’s one of the things I’d really want to improve in a future Nifty version especially with regard to using Nifty with devices like Android. I’ve already have a work in progress implementation of the Nifty layout process in a branch in SVN that will not create any additional objects at all and is a lot faster then what the current 1.x version has to offer.
But there is more planned which means that it will take some time to be available
I have some free time available so I think we can improve the situtation quite a bit for the upcoming Nifty 1.3. On the other hand there are still some feature requests pending … so any concrete help (like svn patches in improving the GC situation would be greatly appreciated
in improving the GC situation would be greatly appreciated