Yeah that's my general problem with all these flamegraphs and other time based tools. There's a bunch of noise!
I'd image for something with deterministic GC (or hell no-gc) you should be able to get a "instruction count" based approach that'd be much more deterministic as to what version of the code is fastest (for that workflow).
The bottleneck of modern hardware (generally) is memory. You can get huge speedups by tweaking the way your program structures and operates on data to make it more cache friendly. This won't really affect instruction count but could make your program run 2x faster.
The latest iteration of this thought process was wondering what would happen if you exposed microcode for memory management to the kernel, and it ran a moral equivalent of eBNF directly in a beefed up MMU. Legacy code and code that doesn't deign to do its own management would elect to use routines that maintain the cache abstraction. The kernel could also segment the caches for different processes, reducing the surface area for cache-related bugs.
[1]: https://web.stanford.edu/class/archive/cs/cs107/cs107.1202/r...
[2]: http://www.codeofview.com/fix-rs/2017/01/24/how-to-optimize-...
A long time ago when people still tried to charge for profilers, I remember one whose primary display was a DAG, not unlike the way some microservices are visualized today. Only the simplest cases of cause and effect can be adequately displayed as a flamegraph. For anything else it's, as you say, all noise.
The value of the flamegraph over the previous iteration was that it more directly showed the chain of events. So no, it doesn't measure it 'just fine'. It's accomplishing absolutely nothing.
Yes, and it continues to show that.
A perf trace for:
async fn foo() -> i32 {
bar().await
}
async fn bar() -> i32 {
baz().await;
whatever()
}
#1 whatever() (somewhere inside it)
#2 bar::poll() (at the cpu_intensive_i32 call)
#3 foo::poll() (at the bar.await line)
#4 runtime executor ... (internals we don't care about)
>So no, it doesn't measure it 'just fine'. It's accomplishing absolutely nothing.
How about you actually try to use it instead of assuming?
That’s a toy example and if you can’t see the bottleneck in a toy example then good luck to you.
If you’re trying to figure out why 5 service calls followed by two more to merge the data together is taking 70ms, it’s not going to be very helpful. If you’re trying to speed up a batch process that makes 400 calls it’s only going to tel you about the cold start and the long tail. Both important problems but not your biggest issue.