Xamarin Profiler Gripes, Suggestions, and Questions

Sorry for the multiple topics here but this is my first time using the profiler and I'd like to bring up some issues, some of which maybe can be answered here, some of which maybe can help the profiler team move forward.

For reference, I've spent most of my .NET days programming video games, and as such have spent a lot of time with the CLR profiler, hunting down allocations and making sure the garbage collector is almost never running. By comparison to the free tool from nearly a decade ago (maybe a decade), the Xamarin Profiler is pretty bad.

Performance

The Xamarin Profiler completely kills my application. I have it taking snapshots ever 30 seconds, so I'm guessing it should be silent inbetween, but my Xamarin Forms app is nearly unusable. I click on a button and it takes ~5 seconds for the app to respond and move to the next screen.

Furthermore, the app itself, which nromally fires up in about 3-5 seconds takes > 1 minute to fire up, and I have to suppress the "app isn't responding" message on the emulator.

The profiler seems to be looking at memory many times - nearly one per second, rather than every 30 seconds...

Maybe this isn't the same as a snapshot but whatever it's doing, it's making my app run way slow.

I should point out that the CLR profiler, whcih seems to investigate and record every allocation can still be used on video games and they maintain 60 fps so long as they're not too complex. Whereas this is not taking snapshots of all allocations, and makes a Xamarin Forms app unusable.

I get it's not the same hardware or underlying tech but from a user experience, it seems unacceptable.

I should point out, if I manually set snapshots, then performance seems fine, and the snaphots behave as expected, but the setting for "every 30 seconds" seems to not do anything except make it take a snapshot every second.

Call Stacks/Object Graphs

I'd like to know the call stack or see an object graph of what is allocating so much memory in my app. In the CLR Profiler I'd see this neat ribbon-like visual where I could look at a type or a caller and follow them end to end, seeing what is allocating so much.

Here I seem to get no information at all. For example, I have lots of strings:

How do I know where those were allocated or what is holding on to those strings? I right-click on the Strings and select "Drill Down", only to get:

This tells me nothing. I would expect to see some kind of object graph by size. So I could tell "Oh, my Person class is holding on to 10 MB of strings, using 35% of all of the memory in my app". I have no idea how to tell this, and of anything that seems to be the most important thing in reducing memory usage.

Similarly the "Call Tree" tab doesn't tell me anything useful either:

When I view the Snapshots tab I can see the types of objects that are eating a lot of memory (this seems promising), but when I want to "Drill Down" to get more information, I get no information:

As mentioned above I'd like to get some kind of tree view where I can expand my objects to see what is using memory within the object.

Cost

The profiler is currently tied to VS Enterprise. I decided to give Enterprise a try (I work comfortably in Community), and if things worked out well enough maybe I'd consider upgrading to Enterprise to kill allocations in my apps....but as is it's definitely not worth it.

Posts

  • VictorChelaruVictorChelaru USMember ✭✭

    I've been working with this a little more and have a little more feedback (hopefully this helps the profiler team somehow).

    I have an app which is allocating and not freeing up a lot of objects. For example, let's look at the Xamarin.Forms.StackLayout, of which my app has a lot:

    I'd like to know where these are being created, and what the path to the root is for them.

    So I double-click the StackLayout row:

    That doesn't tell me much.

    If I click on a particular row, and click on the Stack Trace:

    Or the path to root:

    Note that these are all live objects.

    Based on this information I really don't know how to determine where all these objects are living and where they're coming from...

  • RodrigoMoyaRodrigoMoya ESXamarin Team Xamurai

    hmm, snapshots being taken every second is indeed a bug, that's what's making your app too slow. Looking at it and will release a fixed build soon. Ditto for the paths to roots, it should indeed show information there, specially with so many snapshots. So, can you share with me the MLPD (just File->Save when you're done profiling), and I'll have a look to see why we're missing that).

    As for the call stack, if you uncheck "Track all allocations", we don't record allocations themselves, which is where the stack traces for each allocation are emitted by the Mono runtime profiler. This setting is mainly for when you just want to profile big apps (desktop apps mainly, which generate huge data) and just want to do some sort of "light" profiling mode, just seeing differences (by class) in snapshots, so unless your Android app is doing a lot of allocations, I'd suggest you enable it, so that it records stack traces for all allocations. That's why you get no useful information on the call tree neither, as there are no stack traces from which to build the call tree from.

  • VictorChelaruVictorChelaru USMember ✭✭

    Sure, will send it to you in a PM. Thanks!

  • MuhiMuhi Member ✭✭

    @VictorChelaru
    Any updates on this? I am using the profiler to and seeing the same thing you are. no info when I try and drill down to see what is going on. Thanks , Mo

Sign In or Register to comment.