Profiler is unusable for both iOS and Android

As noted in the other thread: yes this is a bug. The Profiler isn't supposed to crash neither the Editor nor the player. If it does, please report a bug, ideally with a crash report attached. That way we can investigate it, pinpoint it match it up with other reports (via crashlog similarities) which can help isolate the issue, and get some Critical hardware stats that we don't get in forum threads.

 

I think we might need a project to reproduce this. Looks like you are triggering the GC multiple times per second which might contribute towards the crash. Disclaimer: I'm on vacation and only had a cursory look at the logs from my phone.

Btw you might want to change your post to only show the issue ID instead of your private link with which everyone can see the other issues you reported.

 

So judging by the logs there's so much managed memory being allocated that the GC can free ~400KB 4-6 times per second.
Also UserStatsScreen StatsDataLoaded looks like it is trying to deserialize from JSON via newtonsofts JSON tool a type with a generic list on it, triggering generic methods (ThrowHelper_IfNullAndNullsAreIllegalThenThrow_TisRuntimeObject) and while that method is made concrete, it's being registered with he profiler and that's where it crashes.

So really, while we might try to blind fix something, a project would be very good to help us address this because it seems rather unusual scenario with quite the load on the memory and profiler system. Maybe zip one up already to keep a copy of he current state.

 

Well it's very likely a fault with the Profiler code. but It could be FireBase, GameAnalytics or something else triggering the JSON deserialize, an operation which under most JSON solutions is rather allocation happy due to string usage. In this case it seems to be triggered by a webrequest iirc. That GC hammering + incremental GC plus generics is likely a combination that is creating an unusual situation for the profiler code. May I ask why you can't share the project? This seems very worthwhile for us to fix

 

The Profiler can tell you what is allocating so much. Look out for GC.Alloc samples, which are bright magenta in the CPU timeline view, and in Hierarchy you can search for them. The Allocation Callstacks feature can help pinpoint the allocations without need for deep profiling. Not sure what of that would only happen on a device but likely it's also allocating quite a bit in the editor.

 

That's good to hear. Would be good if you could zip it up to conserve the current state until QA gets in touch to provide you can upload link. Or you could create a new bug report, attach he project there and I'll join the two reports as duplicates.

Have you tried turning the incremental GC off and profiling then? Could be a way to isolate the issue and provide you with a workaround until we have a fix (provided it does help). Though having incremental GC on also generally lowers scripting performance through the board, so that'd change performance a bit besides garbage collection times.

Also, if those alloctions are one off, e.g. per scene/screen switch, then it might be fine. If they are per frame or very regular, you might still want to look into ways to reduce them somewhat through caching, pooling and recycling. Also, the link I provided above about Allocation Callstacks contains instructions on how to get more details on all these allocations to take out the guesswork of where they originated exactly in the code and with one hints as to why (based on the mono internal calls in the call stack).

I guess your app is likely not CPU bound but if you have memory issues, it might be good to have a look at these allocations, if the memory issue is in managed (Mono/IL2CPP) memory.

Btw, are you using the Memory Profiler package to hunt down your memory issues? The memory map in the package might show if these usage patterns here leads to managed memory fragmentation, it'd show that, even if the UX for that could and will be greatly improved as we build this tool out further.

 

Thank you, marked as duplicate to link them

So you are destroying the Texture2D and periodically call Resources.UnloadUnusedAssets? Because without that call, only GC.Collect would every now and then get rid of the managed shell objects but retain the native memory until the next non-async/destructive scene unload or asset unload.