Performance is about twenty times slower after upgrading to v10.x

[dsaf]

After upgrading to v10.x (and no other code changes) performance of my MonoGame app became much worse when running on a real device Galaxy S9+ Android 9.0 regardless of whether a debugger is attached or Release/Debug build configuration is chosen.

environment.txt contents are commented out so it runs default.
The default 23_x86 emulator performance is not bad, not sure what to make of this.
Based on my observations performance hit appears to be CPU-bound (rather than GPU).

1. What could be the reason and solution?
2. How can I roll back to older Xamarin with more stable performance?

Version Information

Microsoft Visual Studio Community 2019 Version 16.3.6
Xamarin 16.3.0.277 (d16-3@c0fcab7)
Xamarin.Android SDK 10.0.3.0 (d16-3/4d45b41)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: mono/mono@5608fe0abb3
Java.Interop: xamarin/java.interop/d16-3@5836f58
LibZipSharp: grendello/LibZipSharp/d16-3@71f4a94
LibZip: nih-at/libzip@b95cf3fd
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@8212a2d
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-3@cb41333

[dsaf]

I tried two new emulators and the performance seems to be different between OS/API versions:

1. Emulated Pixel 3 XL Nougat 7.1 API 25 - decent performance.
2. Emulated Pixel 3 XL Pie 9.0 API 28 - terrible performance.

Is there something specific about Xamarin v10 and/or API 28 that makes performance 20 times worse? Am I doing something stupid unknowingly? My app is using Target Framework = Android 8.1 (Oreo). I tried targeting 9.0 but it did not help.

[pjcollins]

Would you be able to provide some more information about the performance issue you are encountering? How are you measuring the differences in performance? Would you be able to provide some source which reproduces this problem?

[dsaf]

@pjcollins It's a drop in frames per second. It's present on every scene and is particularly bad on the CPU-heaviest one. Performance used to be around 60 FPS and now is 3 FPS. I don't know where is the problem and there is a lot of code there. Would you be able to provide me with a community version/license of any Xamarin profiler? Alternatively please give me some pointers about where the problem might be roughly.

[dellis1972]

@dsaf Do you get the same kind of issue on a Default Android MonoGame app? This could possibly be a performance regression in mono itself or a problem in MonoGame since it doesn't not use OpenTK any more. Given you seem to think the issue is CPU bound that points to runtime performance.

This kind of problem is really hard to diagnose without some hard data. I would recommend using the StopWatch class and writing some output to the console try and see where the slow down it happening. Its hard to give you pointers since we don't know what code you have written. On a general level I would try to avoid using anything that would allocate memory (like Linq etc) in your Update/Draw loop. But I suspect you will have done that already.

To downgrade you can get old versions from https://github.com/xamarin/xamarin-android/#downloads. Now you won't be able to install that since you have a newer version. So what you can do is decompress the vsix to a directory and copy the contents into the appropriate locations

• C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Xamarin\Android
• C:\Program Files (x86)\Microsoft Visual Studio\2019\ Community\MSBuild\Xamarin\Xamarin.Android.Sdk.props
• C:\Program Files (x86)\Microsoft Visual Studio\2019\ Community\MSBuild\Xamarin\Xamarin.Android.Sdk.targets
• C:\Program Files (x86)\Microsoft Visual Studio\2019\ Community\MSBuild\Novell
• C:\Program Files (x86)\Microsoft Visual Studio\2019\ Community\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid

Backup those locations first, and if that works hopefully you will be on the previous version.

If you manage to downgrade , it would be really helpful for us if you could provide timings on the before and after.

[dsaf]

@dellis1972 Thank you for responding and the helpful points.
Just to avoid going in a wrong direction: as I mentioned in my second comment I am also observing same 20x difference in FPS between 7.1 (25) and 9.0 (28) emulators (x86) on the same code and build.
Does it not mean that the problem is with how the same code runs under different OS versions or something like that rather than code itself?
I will try the Default Android MonoGame app measurements as you suggested soon but just wanted to ask and double-check meanwhile.

Since you brought this up, in terms of garbage collection my application allocates constantly and frequently by design (kind of like path 2 from http://www.shawnhargreaves.com/blog/twin-paths-to-garbage-collector-nirvana.html). That is a byproduct of my target research architecture. While it might sound questionable from traditional optimisation point of view in practice I was able to achieve 60 FPS with several automatic minor garbage collections per second and an automatic major collection every few seconds without perceptible pauses up until recently. There is no manual garbage collection apart from application/scene startup point and the MONO_GC_PARAMS are default since during my past experiments I determined that the defaults are actually beneficial for my scenario (it turned out that both collecting large amounts rarely and tiny amounts ultra-frequently led to bad user experience with respectively either very perceptible intermittent freezes or a general slowness).
So unless there is something new about Xamarin 10 or Android 9.0 or API 28 that is particularly punishing for such a GC usage, that should not suddenly be the problem?

[radekdoulik]

Could you check which ABI is used in both cases? (before the regression and after) I wonder whether it might be 32bit vs 64bit difference.

[dsaf]

@radekdoulik Thank you, I tried this but it did not make a difference.

I have rolled back to previous Xamarin and now able to see some promising changes in how code behaves. It might turn out to be my mistake or my mistake + some other factor. I will investigate further and report my findings.

[jonathanpeppers]

@dsaf let us know if you get more info, closing for now as we haven't heard back in a while, thanks!