Profiler in Editor File.Read taking up a huge amount of CPU

Hello

As @alexeyzakharov said, this sample does not prolong your frame time, it just happens to last as long as the frame while it is waiting.

What is actually taking up most of your time is the EditorLoop, which in your screenshot is collapsed into that gray sample on the main thread. This might include Editor scripts and editor extensions you're using but is likely, to a good part, spending time to Calculate stuff for the Editor including rendering the Editor's UI, including the Profiler Window (which is sadly not the most lightweight window that we have, due to the sheer number of data points. Not saying that is isn't in always in need for more optimizations)

This is a known pain point when profiling in the Editor. Additionally, there are all kinds of things going on in the editor that mean that performance will be quite different from a build, even if it is a standalone build, and even more so when targeting a non-Desktop platform. There are some things we can and will do to improve the experience and accuracy when profiling in the Editor (and/or to keep iteration loops tight) but profiling the Editor is always just going to be an approximation.

The best practice when trying to optimize a product made with unity is to profile a build on the target device (ideally on the low end of the targeted spectrum). Data from these Profiling sessions should be used to identify areas that should be investigated further, either directly on the device where feasible, or in the editor. For tight iterations while optimizing, profiling the editor can be helpful but the end result should always be evaluated in a build on the target device.

That said, if you want to find out, what the Editor is spending so much time on, you can switch on "Profile Editor" to see the entire frame of the Editor with the Player running within it.