Does SkiaSharp 3.0 possibly do large new array allocations at some point in the code in a NET 9.0 MAUI Android app?

[TommiGustafsson-HMP]

I'm trying to find a reason for excessive System.Private.CoreLib!System.String.memcpy(byte*,byte*,int) calls in our .NET 9.0 Android MAUI app, which uses SkiaSharp 3.0-preview2.1. The calls are reported by dotnet-trace and speedscope. The method is called by Mono VM when creating a new array instance. We are using SKGLView and SKCanvasView in MAUI, and each frame painted with either of them reports several milliseconds of memcpy. The question is, is there some point in managed SkiaSharp code where large allocations of new arrays could be happening?

[mattleibow]

hmmm, I don't think so.

If you comment out all your code in the draw loop, does it still happen? Can you try draw in chunks and uncomment bits at a time to see where/what is doing a copy.

That looks to be a big string copy from pointer data. So there may be a case where some string value is being read from native code.

Is this happening in 2.88.x?

[TommiGustafsson-HMP]

We were able to fix the thing by changing some structs to classes. However, it did not affect performance at all, which means that speedscope falsely reported the thing as a performance issue. It turned out that the real reason for the performance degradation was a too small GPU resource cache size. Please see:

#2555 (comment)

However, we are not sure why Android devices require such a huge GPU cache.