WaitForPresentFamily is sick so I spend part of the day integrating Tracy profiler into Everything is fine as it also comes with fiber support. My plan is to still use my native profiler as it has less friction (you press a button and get profiler data overlayed on your window), but switch to tracy when switching it's other juicy features (network profiling and serialization amongst many others). The integration was really quick (about 1 1/2 hrs), only minor issue was my use of dynamic strings in the profiler
Now when viewing the data I have the problem that I just run too many fibers (256 to be precise). This leads to the view being cluttered with lots of scattered data points and is REALLY hard to read. I can't really find a way to reduce this somehow. In my native profiler I pin each thread to a logical core and then project the fiber data onto the thread that it is running on. This probably only works in this setup but it leads to a pretty clean overview that you'd also have without the fibers.
I can't really find a good solution inside the tracy profiler viewer and the documentation also does not mention anything along these lines, so I am thinking of not actually using the fiber interface of tracy and instead keep a stack of profiling scopes per fiber and manually close them and reopen them when switching fibers. This adds overhead when switching the fiber but I don't think it's too bad. Maybe there is also a solution that I have not yet thought about or come across @wolfpld
Bartosz Taudul@WaitForPresent I would like to have the per-thread view of fiber execution, but I don't use fibers, so this has low priority.
@wolfpld Fair enough, Fibers are not really a widely used feature afterall! Thanks!
slembcke@WaitForPresent @wolfpld I mildly have this issue, but my scheduler’s fiber pool is a stack so it mostly reuses the same fibers over and over. Would still be handy to have a fiber-on-thread view if that’s coming. :)
