"Stack traces without user methods" in a console application

Since there is no call tree, selected filters and other necessary data it's hard to say what's wrong here.

If you are sure that your methods are under `Stack traces without user methods` you probably added some of your modules into the system modules list. If it's the case you can fix it in settings (just remove "user" modules from "system" modules list, or just press `Reset to defaults` if you don't care).

Hi Kirill, 

unfortunately, the "Call tree folding" was set to Defaults, so this is not going to be the source of the problem. 

Im using a clean installation w/o changed to default settings. What additional info about the problem would help to determine the cause? 

Thank you, 

Daniel

If so, most likely you have seen an expected result.

Hotspots view displays the methods that are most likely are the root of the issue: https://www.jetbrains.com/help/profiler/Plain_List.html . For example if the Main() does nothing but call other "User" methods there is nothing to fix in Main and we won't show it in hotspots.

As for the Hotspots list. If you cannot optimize LZ4Stream or any other methods in the list you must consider them as System methods and mark them accordingly in dotTrace (using context menu for example).

But in fact I don't understand what task you are trying to solve. You are using Trace (or even Line-by-Line) profiling type and I see huge amount of calls for some tiny methods. Most likely the measure results are at least inaccurate. Make sure you selected proper profiling type for your case: https://www.jetbrains.com/help/profiler/Basic_Concepts.html

The result you see can be caused by using improper profiling type.

Anyway if the result you measured is correct and you still don't see your methods in hot spots, you can navigate through call tree, or even find a method (Ctrl-F) you are expected to see in snapshot. But it depends on what task are trying to solve and what are trying to find.

Kirill, thanks for having the patience with my question. 

What you said about the Main method ('For example if the Main() does nothing but call other methods there is nothing to fix in Main and we won't show it in hotspots.') applies to other methods as well? Because if so, I dont undestand how you can find a bottleneck of anything. For example, in a previous version of my library, I was doing lots of unnecessary casts. So the IList.GetCastedTo<T>() was the pain. But it called only a list allocation and a foreach - so this also 'just called other methods' and yet there was something to fix.

Just for clarity, Im running on a fresh installation of W11 and VS2022 - just to be sure no settings of either OS or IDE are having some unexpected impact.

I went ahead and played around with the Hotspots window, applying filters and what caught my eye:

• the total runtime is around 760 seconds (arrow 3)
• the Main() spends 95+% in a method called QSearch_main.Run() which is also confirmed by the measurements (arrow 1, 2)
• however, Main() consumes only 15% of the total runtime - where is the remaining 85%?

Its there anything in code that can generally mess up the profiler? The screenshot comes from a Tracing result, not line by line, so I assume that 85% can't all be profiling overhead. 

Thank you, 

Daniel

About hotspots and how dotTrace can distinguish bottleneck methods:

We can divide all methods into "User" and "System" methods. What is a "System" method? The method you have no control at, you cannot optimize such methods, the only thing you can do is not to call this method from "User" methods. I think now it's obvious what are the "User" methods. So we analyze the whole subtree to calc the metric Own+System time. So if method do some work (for example cast), or call a system method that takes a lot of time the method most likely could be optimized. But if user method just call another user method usually there is nothing to optimize here.

 But it called only a list allocation and a foreach - so this also 'just called other methods' and yet there was something to fix.

 It's not correct, the method spend some time doing a work (in this specific case foreach and allocations).

• the total runtime is around 760 seconds (arrow 3)

As I said before I don't see the whole picture since you hid all filters, but as far as I can deduce, your application have at least 3 threads with user code, and probably few system threads. If so total time (760 seconds) is not a run time. The total time is a sum of times application spend in all threads. If we oversimplify this (note: it's just oversimplified example, in ideal world nothing more) the total time = threads count * run time.

• the Main() spends 95+% in a method called QSearch_main.Run() which is also confirmed by the measurements (arrow 1, 2)

Moreover according what I've seen in screenshots QSearch_main.Run() also just spend some time in other user methods and there is nothing to optimize here.

• however, Main() consumes only 15% of the total runtime - where is the remaining 85%?

Just check it, by default all system methods are "folded" by default, but you can unfold any folding: https://www.jetbrains.com/help/profiler/Folding_Calls.html#filtered_calls . I see no reason you would like to explore system calls, but if necessary you can find where the "System" spent it's time.

Its there anything in code that can generally mess up the profiler? The screenshot comes from a Tracing result, not line by line, so I assume that 85% can't all be profiling overhead. 

Please read the article I've send you last time: https://www.jetbrains.com/help/profiler/Basic_Concepts.htm . I can be mistaken, but according to what I've seen at the first screenshot you shared, you should use "Sampling" instead. As for the question: if you have irrelevant data it's impossible to fix an issue, you could optimize profiler overheads instead of real issue. Most likely it's not related to 85% you mentioned (I've explained everything about total/run time and system code/threads before).