Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
In Xamarin.Android 126.96.36.199 for VS2015, Java.Interop.dll is built using DEBUG conditionals, making
JniObjectReferenceManager.AssertCount(int count, string type, string value)
JniObjectReferenceManager.AssertReferenceType(ref JniObjectReference reference, JniObjectReferenceType type)
available at runtime. Those two meshots take a lot of CPU when managing references, making useless string.Format calls.
> Those two meshots take a lot of CPU when managing references,
> making useless string.Format calls.
Does it? As per Bug #41733, the overhead from those methods is negligible so long as the asserts don't actually fire:
> Xamarin.Android 6.0 results: 264-351ms
> Xamarin.Android 6.1 + "workaround": ~240-300ms
> [the patch] appears to have alleviated the performance problem.
A closely related question is, how useful do you want the JNI Local Reference count to be? If you don't care at all, then the assert is meaningless. If you won't want completely "funky" negative numbers, then the assert is meaningful because it shows a problem.
Another issue is our distribution process: at present we have no facility to provide both Debug and Release-compiled assemblies. (I can *imagine* one, but it doesn't currently exist.) For years we've actually been shipping Debug-compiled assemblies, and it hasn't been a problem, but we also haven't had lots of asserts either...so that might be why, and it might be prudent to start looking into shipping both Debug- and Release-compiled assemblies.
The asserts don't fire, but both string.format is always executed, that's what is costly enough to appear in the profiler on a simulator.
And for the other counters, I was not aware those may be useful at all, so I don't have on opinion on this...
And I agree with the problem of distribution, though a unconditional method call is cheap enough that having a check for a static variable can enable these asserts, if necessary.
The unnecessary string allocations are h handled with: https://github.com/xamarin/java.interop/pull/55
@Jonathan, I have tried to reproduce this Issue using attached project mentioned in https://bugzilla.xamarin.com/show_bug.cgi?id=41733#c0, Application getting deployed and launched on device but I am not sure where I can check CPU utilization for those two meshots.
Could you please let me know how can I reproduce this Issue so that I can verify it.
This already shipped in Cycle8. Marking as verified after validating the code change is also present in Cycle9.