Add built-in way to have the profiler "wait" for X amount of time

[BenAdvocatia]

When using the self-profiling API, it would be useful if there was a built-in way to have the profiler wait, after being started, for X amount of time without having to use something like await Task.Delay() or Thread.Sleep. This causes that "wait" to usually blow out the rest of the graph, making it not as useful for quick glances to determine bottlenecks. While I can remove that method from the viewer, it'd be ideal for it to not have to be there in the first place.

[gassanosh]

Could you please clarify what do you mean? You need some data to be excluded (not gathered)?
When you call StartCollectingData the dotTrace starts collecting data. You could run StopCollectingData to pause collection. Combining those methods, you could exclude any "waits" from the resulting data.

[BenAdvocatia]

Sorry for the late response. What I'm wanting is to use the self-profiling API to stay active and profile the entire application for a period of time, instead of just some specific snippet of code. Similar to if I installed the profiler on the machine and just let it capture data for a few minutes to get a more general profiling. I'm using ASP.NET 8, and I could probably just have two endpoints, one that starts capture, and another to stop capture, but with how our infrastructure is configured, it would be a lot nicer if we could hit one endpoint and have that start profiling, wait X amount of minutes, and stop the capture.

Currently, I'm having to start the capture, add a await Task.Delay(TimeSpan.FromMinutes(mins));, stop the capture, then send the files to some central location off the EC2s. Unfortunately, that Task.Delay blows out the graph, as shown in the initial post.

[gassanosh]

First of all, when you call StartCollectingData, profiling starts for the entire process, not just a specific snippet.
If you want to profile synchronous code, you can wrap it with Start/Stop. Later, when analyzing, you can filter by your thread to see only the data from that snippet.
This won’t work well for a multithreaded app. Your calls will be spread across multiple threads, and you’ll also see other activity in the app (dispatchers, etc.), just like in your screenshot.
Usually, this isn’t a problem because dotTrace provides powerful filters to easily exclude irrelevant code.

If you don’t want StartCollectingData/StopCollectingData to interfere with your tasks, run them on a separate thread.
For example:
new Thread(() => { DotTrace.StartCollectingData(); Thread.Sleep(1000); DotTrace.StopCollectingData(); }).Start();
And that's the best you could do if you don't want to "cut" irrelevant time using Start/Stop brackets.
Anyway, dotTrace always collect data from the entire process. That’s why you see all activity. Just filter out irrelevant time in the snapshot using dotTrace’s filtering system.