VM, Heap & MonoGame performance


While developing our new game, I stumbled upon what seemed to be a strange Mono/dalvik behavior.

We noticed with our new project that there were some serious hickups, even on devices performing very well (framerate drops from 60 to 45fps every 5-10 seconds).

Debugging the app revealed that these hickups are the consequence of a lot of Davlik GC_FOR_ALLOC and Mono minor (nursery) collections. There is something like one davlik collection every 5-10 seconds and one Mono collection every 30 seconds.

In order to identify the problem, I reduced the scope of the game, down to… the most minimal MonoGame example: the empty cornflower blue template. Launching it exposes the problem quite quickly.

I never noticed this on our previous project, probably because it was more memory intensive and that Mono & Davlik quickly promoted their heap size (hence, less frequent garbage collection). But it looks like low memory/memory efficient applications are impacted by small heaps barely promoted to bigger size. (But I’m no VM expert, so any comment is welcome.)

Profiling the cornflower blue template shows some garbage (mostly strings, char[] and byte[], what seems to be StringBuilder buffer resizing work). Mono collects just a few hundred KB every 30sec, while Dalvik collects up to 5MB of strings/char every 10sec.

Strangely enough, it seems that the Mono collections happen also on iOS (every 10-30sec), but with a different garbage collector, I would assume more different results. But that may be my imagination, I haven’t thoroughly profiled the iOS build.

So, here are some questions, which may be a little naive with my VM knowledge:

  • is this a normal behavior?
  • if there’s so much Dalvik garbage, does it mean that Mono itself have leaks?
  • I am tempted to boost the heap size manually, but that would not be effecient and would not get rid of garbage collection, just temper them?

Comments appreciated. :slight_smile:

Dalvik is the Java VM right? We don’t directly have any Java code in MonoGame… anything there caused by us has to be from some C# API that indirectly triggers Java garbage.

@daveleaver @KonajuGames Any ideas?

We’ve done a lot of work to keep MonoGame garabage free at runtime. In general we just generate garbage during resource creation like textures or other content.

If you spot anything that MonoGame is generating let us know.

Yes, Dalvik is Android’s Java VM.

I know that MonoGame has been well designed regarding memory allocation and that if the Java VM generates garbage, it is due to Mono operations and not MonoGame directly.

I haven’t been able to make the Mono profiler to work, so the only profiling results of MonoGame that I have are from the .Net CLR and profiler, and it shows absolutly no leak.

Still, on Android (4.4.4 Nexus 7), Mono (Xamarin Android 4.12.6) fires those minor collections every ~30sec:

[Mono] GC_MINOR: (Nursery full) pause 87.68ms, total 88.04ms, bridge 51.79ms promoted 880K major 1088K los 226K

Without a working profiler, I have no idea what those are about.

Also, I stumbled upon this SO post, showing that the empty Xamarin AndroidGameView template behave the same.

This and the fact that there is no garbage with the SharpDX version make me think that the problem is on the Xamarin side. If it is so, I will check that with Xamarin.

That SO post you’ve linked make it sound like a Xamarin bug. Have you, or could you please post an issue on their issue tracker and link it here?

Is reproducing this as simple as making a new monogame android project, hit run, watch the android debug log?

I think so too, it really looks like a Xamarin issue. I will post a bug report then, and yes, it is as simple as making an empty android project (no content loaded, no draw calls) and watch the log output.

1 Like

FYI, the bug report.

Looks like the issue has been fixed and should be deployed along with the next Xamarin Android 4.14 hotfix (which is not yet publicly available).

I noticed this the other day too. My test app with a simple rotating model was stuttering periodically in time with the Dalvik GC messages in the logcat output. Looking forward to Xamarin.Android 4.14 making its way to stable.

Hi all, I just signed up to the MonoGame community to ask if anyone is having this exact issue and found this thread.

I’ve been pulling my hair out over this, optimising to the max, yet still getting fps dropping to 40 every few seconds.

The strange thing is that I get constant 63fps on exactly the same build on my Samsung Galaxy S2 (Android 2.3) and the OUYA, I’m only getting this dip in performance on my Samsung Galaxy S4 (Android 4.4.2).

So looks like a Xamarin issue, fingers crossed!!

Hi there,

Xamarin Android 4.16 released today and supposedly fixes this issue.
Unfortunately the problem is still present on both OpenTK-1.0 and 0.9 branches (MonoGame uses the latter).

I am therefore re-opening the issue…

Is there any update on this? I just created a new android game and the performance is terrible. I ended up removing everything that I had and the fps drops from 60 to 45 every few seconds. I tried this in iOS, android, windows, and OS X. The only platform I am having issues with is android. I also noticed that there is no OpenTK dll referenced. Any advice would be great.

Sorry for re-upping this old thread, but, was this fixed?


@dellis1972 - Did this get fixed on Android by Xamarin and did we update OpenTK?