You're correct that we don't show you function invocation counts, because we use statistical sampling. What you want would require us to record every single function call, and this would have a very high overhead, and give incorrect timing data. Since the most important thing is to accurately measure function times, so you can optimise the right thing, we use sampling (you can read more about it, here: http://www.adobe.com/devnet/scout/articles/accurate-profiling-with-scout.html).
If you really want to measure the number of times a specific function is called, you can use custom Telemetry. Since this uses instrumentation rather than sampling, it will record every function call. Be careful though - if you insert custom telemetry into a fast function that gets called really often, the overhead will skew the data you see in Scout (it'll look like the function took a lot longer than it did). So, I would suggest that you run Scout normally (i.e. with no custom telemetry and no 'high-overhead' settings enabled), to determine which functions take the longest, and then use custom telemetry to investigate how often these functions are called. You can find out how to use custom telemetry here:
You'll see your custom instrumentation in the Top Activities and Activity Sequence panels. If you right-click on the table header in the Top Activities panel, you can turn on the "Count" column, which will show you what you want.
Another option you could use, is the memory allocation tracking feature. This records all allocations, so it'll give you an accurate count of the number of times a function is called, so long as it always allocates something (it won't show you function calls that don't perform any allocations). Of course, timing won't be accurate with this turned on, because the overhead is high.
Thanks for the answer Michael. The estimation by taking stack snapshots indeed explain why you cannot record the number of calls. I will look into using custom Telemetry.
I still think having an accurate tree and invocations counts could be useful to have. If the tradeoff is a high overhead, it would be a different option in the list of Settings for New Sessions. But I guess that would require updating more than just Scout.
We did investigate a "tracing" profiler earlier in the development of Scout, but it was such high overhead that we didn't include it. We may consider adding this as an optional setting at some point in the future - thanks for the feedback!