Investigate Java collection wrappers performance

[jpobst]

Investigate if any of the methods provided by our Java collection wrappers (JavaList, JavaDictionary, etc.) could be implemented more efficiently.

For example, JavaList implements ToArray () by calling java.util.List.get (int) for each item in the List, resulting in a lot of marshalling overhead.

Could we instead call java.util.List.toArray () to retrieve all of the items in one call?

Another possibility might be to add something like ToImmutableList () to efficiently move a copy of the list to C# that no longer needs to be kept in sync with Java?

[jonpryor]

@jpobst: short version: try it and let's find out. 😅

That said, there may be some semantic complications. We don't have any constraints on the T of JavaList<T>, meaning JavaList<int> is supported. However, Java doesn't support ArrayList<int>; it requires ArrayList<java.lang.Integer>. We make this work by centralizing all of the type conversion logic in JavaList<T>.InternalGet():

android/src/Mono.Android/Android.Runtime/JavaList.cs

Lines 43 to 46 in b74d0fe

	return JavaConvert.FromJniHandle (
	obj.Handle,
	JniHandleOwnership.TransferLocalRef,
	targetType);

It should be possible to rework things so that a single toArray() call is involved, but I suspect (without evidence) that our various type coercion & marshaling code will dominate.

Another possibility might be to add something like ToImmutableList () to efficiently move a copy of the list to C# that no longer needs to be kept in sync with Java?

I'm do not understand the suggestion. If you need a C# list that isn't kept in sync w/ Java, why not just new List<TWhatever>(javaList)?

[jpobst]

Another possibility might be to add something like ToImmutableList () to efficiently move a copy of the list to C# that no longer needs to be kept in sync with Java?

I'm do not understand the suggestion. If you need a C# list that isn't kept in sync w/ Java, why not just new List(javaList)?

With the current setup, new List (javaList) has the same undesirable performance characteristics as JavaList.ToArray.

If that can be fixed to be O(1)-ish instead of O(N) then a new method that efficiently does it isn't needed.