Anyone heard anything about this? This is profiled with a built player
Are you talking about those red spikes?
Please provide more information.
It’s not surprising however to see some memory acquisition in the background even if your project is not acquiring any memory at the very moment.
Since C# is a managed language it tries to maintain a buffer so not every request of your code for memory, has to go all the way to the OS (which is the slowest way to acquire memory).
Also you will see a CPU spike in the background as well at times due to the garbage collector.
Don’t worry about it as long as it remains in the background thread.
You can see in the hirarchiy what code is allocating, some kind of file system watcher.
It doesn’t matter if the allocation is happening in the background the collection will halt the entire app domain
1 Like
It would be great if unity could shed some light on this allocation because I can’t find anything relevant when I google
Hey unity im getting crazy trying what his background thread is that allocates like crazy
Can you please shed some light?
This is a built player with a stand alone profiler.
Select raw hierarchy, make deep profile build, select deep profile in profiler and unroll whole call stack. I wouldn’t be surprised if it’s a standalone profiler thread.
1 Like
Thanks, but the raw one doesnt seem to output it different than the none raw one
Unroll DefaultWatcher. Is it the same with editor profiler? What about empty project?
It’s not there for a empty project it seems to be connected to XR plugin. Or possibly SteamVR but the steamvr code is open source and I can’t find any DefaultWatcher code there. These is also no clues deeper down like a call to my code or SteamVR or any other code other than generic framework code
I tried recording GC.GetTotalMemory(false) and then log it at application exit and it could not detect any allocation (Built player)
Well if you are only recording this at exit, then ofcourse GC will likely have cleared itself by then.
Without explaining exactly how you are recording it and showing code, its really hard to point out what the problem likely is, both for us and for Unity engineers.
I was wrong above: I recorded from update loop it was to seldom. I instead recorded from a background thread. Now it detects allocation. Which means its not profiler polluting the result
I recorded during run and logged at application exit, What do you take me for? (Logging allocates)
Well your previous comment alone shows exactly why I was asking how and what you logged, as clearly it was the culprit. So no need to get arsey mate, no point coming on a technical forum if you dont want to get asked about how and what you are doing 
Either way glad you figured out what was giving you an erroneous output 
I found the culprit, package com.valvesoftware.unity.openvr uses a System.IO.FileSystemWatcher in OpenVRLoader.cs
It wasnt visible from my code since they reside in another sln
I really dont know if we should blame package creator here or that Unity mono allocates in filewatcher
While looking into this I had a feeling it might be related to something involving VR. You may want to start saying as much in your posts because most people aren’t going to think to look there let alone remember you’re developing for it.
2 Likes
Looks like there is an issue being discussed on the package’s github here: SteamVR alloc 1.7k on a background thread · Issue #1077 · ValveSoftware/steamvr_unity_plugin · GitHub
3 Likes
Cool thanks! Seems to be same issue! I just tried in a vanilla .NET core project and the watcher does not allocate there.
Granted, it is rather unstable but just for the record: Standalone Profiler is a pure Editor concept. None of it’s code lands in or affects the Player.
2 Likes