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.
Hi, I posted this at https://forums.xamarin.com/discussion/97915/instantiating-java-object-from-c-many-times-is-very-slow/p1?new=1 recently, but I figured Bugzilla would be more appropriate. I'll paste my original post here so you don't have to follow the link.
I'm working on a Xamarin.Android app that offers syntax highlighting for code. I am calling `new ForegroundColorSpan(color)` very frequently in a loop, and this is the only piece of Java code that I call from C# while syntax highlighting. For large files with thousands of lines of code, the app takes an extremely long time to load. I have done some random sampling via pausing the debugger repeatedly while the files are loading, and the debugger keeps stopping on the above line. [This](https://github.com/android/platform_frameworks_base/blob/master/core/java/android/text/style/ForegroundColorSpan.java#L30) is all there is to the implementation of `ForegroundColorSpan(int)`, so I strongly suspect it has to do with Java interop.
Is there anyway to work around this? I have tried caching ForegroundColorSpans for the same color via a Dictionary, but due to the way the Spannable APIs are designed one cannot call SpannableString.setSpan with the same span object for a different range.
Hello, so I looked a bit further into the issue by manually implementing Java bindings after reading the "Working with JNI" document on the Xamarin website. I wrote this
[Register("android/text/style/ForegroundColorSpan", DoNotGenerateAcw = true)]
internal class FastForegroundColorSpan : JavaObject
private static readonly IntPtr class_ref = JNIEnv.FindClass("android/text/style/ForegroundColorSpan");
private static IntPtr id_ctor_I;
[Register(".ctor", "(I)V", "")]
public unsafe FastForegroundColorSpan(int color)
: base(IntPtr.Zero, JniHandleOwnership.DoNotTransfer)
if (Handle != IntPtr.Zero)
if (id_ctor_I == IntPtr.Zero)
id_ctor_I = JNIEnv.GetMethodID(class_ref, "<init>", "(I)V");
var args = stackalloc JValue;
args = new JValue(color);
var handle = JNIEnv.NewObject(class_ref, id_ctor_I, args);
Now when I pause the debugger randomly, it's always on SetHandle(). So that appears to be the bottleneck.
You can view the source code of my app here: https://github.com/jamesqo/Repository/blob/1ac7fb86b80199e4aa3e02b980afa25a4bc9eb78/Repository/Internal/EditorServices/Highlighting/FastForegroundColorSpan.cs#L35
Link to SO question where I posted more information: https://stackoverflow.com/q/44603453/4077294
Is this still an issue for you? It seems that you're aware of the difference between GREF limits on the emulator vs a physical device and you resolved it on your end. Thus I'm marking this bug as RESOLVED ANSWERED for the time being. If it's still an issue, please change the status to REOPENED or comment on this thread and I will do it for you: