Bug 21428 - AndroidGameView leaks and performance issue
Summary: AndroidGameView leaks and performance issue
Status: RESOLVED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 4.12.4
Hardware: All All
: Normal normal
Target Milestone: 4.14.0
Assignee: Radek Doulik
URL:
Depends on:
Blocks:
 
Reported: 2014-07-18 06:29 UTC by Thomas Altenburger
Modified: 2014-09-03 11:40 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Thomas Altenburger 2014-07-18 06:29:15 UTC
Hello,

It looks like AndroidGameView leaks, resulting in very frequent garbage collections on both Mono and Dalvik VM, and heavy framerate hickups.

How to reproduce: create an empty Android GL Application, run, monitor the logcat output.

There are Dalvik GC_FOR_ALLOC every 1 to 10 seconds, collecting up to 5MB of what appears to be StringBuilder and Thread operations (according to DMMS profiler).
There are also Mono nursery collections every 15 to 30 seconds, but I don't know what it collects since I haven't been able to make the Mono profiler to work.

Tested on Xamarin.Android 4.12.6 & Nexus 7 (4.4.4).

PS: it impacts a lot MonoGame Android projects, for more detail on this issue, see this discussion for reference: http://community.monogame.net/t/vm-heap-monogame-performance/820
Comment 1 Pete 2014-07-18 14:38:29 UTC
I can confirm this. In fact, I was just about to open a new bug report, when this was suggested.

It even happens after a few seconds is release mode; you can see rendering stalls happen randomly.

It also impacts WaveEngine projects for Android: http://forum.waveengine.net/forum/general/3666-fixed-time-step-on-mobile-devices

Tested on the latest Xamarin.Android (also happens in previous versions) and Samsung Galaxy Ace 3 device (4.2.2), and Edison 1 tablet (4.1).
Comment 2 Pete 2014-07-18 15:46:58 UTC
Btw, setting env parameters for the project to something like ...

# Set parameters for Mono's GC.
MONO_GC_PARAMS=nursery-size=256m,soft-heap-limit=128m

... seems to help a bit, but the stall is still there from time to time even if no  garbage collection occurs.
Comment 3 Thomas Altenburger 2014-07-18 16:30:04 UTC
Of course it helps to increase the heap size, because garbages have more room to gather, hence less frequent collections. But it is not an healthy coding approach to adopt, as it only masks things. ^^
Comment 4 Pete 2014-07-18 17:07:41 UTC
Agreed. The reason why I use such options is to find out whether it is related to GC. 

As I said maybe it has nothing to do with GC, since the stall seems to happen even when no GC is done. Maybe it's a problem related to the AndroidGameView's loop.
Comment 5 Pete 2014-07-24 12:47:55 UTC
Any news on this report?
Comment 6 Pete 2014-07-29 08:20:48 UTC
Anyone?
Comment 7 Radek Doulik 2014-07-29 14:37:08 UTC
This should be fixed in 4.14.x.
Comment 8 Thomas Altenburger 2014-07-29 14:46:26 UTC
Thank you for the reactivity.
Comment 9 Pete 2014-07-29 14:49:19 UTC
Thanks a lot!
Comment 10 Pete 2014-08-06 20:34:10 UTC
Hi, sorry to ask but I need to know whether this fix has been released on the current stable version.
Comment 11 Pete 2014-08-07 16:57:26 UTC
Could you guys please specify the target milestone in the corresponding field? 4.14.0, 4.14.2, etc.
Comment 12 Radek Doulik 2014-08-13 08:19:54 UTC
it should be fixed in 4.14 stable release - that's the issue with allocating memory and frequent garbage collection.

there will be more improvements in 4.16 where it is possible to have the rendering run on non-UI thread, which improves the rendering fluency.
Comment 13 Pete 2014-08-13 13:35:47 UTC
Ok, thanks.
Comment 14 Pete 2014-09-03 11:40:30 UTC
I guess 4.16 should be released this September. ETA?