3 ms·

>The value of the flamegraph over the previous iteration was that it more directly showed the chain of events. Yes, and it continues to show that. A perf trac

>The value of the flamegraph over the previous iteration was that it more directly showed the chain of events. Yes, and it continues to show that. A perf trace for: async fn foo() -> i32 { bar().await } async fn bar() -> i32 { baz().await; whatever() } ... that happens to be captured while `whatever` is executing sees a callstack that is: #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) The flamegraph records the CPU usage accordingly. >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?

hinkley 4y ago
> Yes, and it continues to show that. 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.
- Arnavion 4y ago
  I use flamegraphs to investigate perf issues in a distributed system at my day job. But it's okay. Keep being confident about your ignorance.
  - hinkley 4y ago
    I also use flamegraphs. And log files. And stats (duration, counts, memory, etc). And a debugger, microbenchmarks, htop, {io,vm,net}stat, human behavior (Steve's code tends to have this sort of problem), dead reckoning, educated guesses, staring at the code, and even on occasion brushing my teeth, going for a walk, or washing my hair. Getting the job done in spite of bad signal to noise ratio from tools is just part of the job description - for a very senior person. The SNR for flamegraphs is dropping, doubly so for junior and mid-level developers. And as I said in another thread a few days ago, we're also hiding data in 'modern' perf tools, which indicates to me that even the tool writers are missing some tricks. These days it's just easier to bump the cluster size from 18 to 21 machines and move on.

hinkley 4y ago

> Yes, and it continues to show that. 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.

Arnavion 4y ago
I use flamegraphs to investigate perf issues in a distributed system at my day job. But it's okay. Keep being confident about your ignorance.
- hinkley 4y ago
  I also use flamegraphs. And log files. And stats (duration, counts, memory, etc). And a debugger, microbenchmarks, htop, {io,vm,net}stat, human behavior (Steve's code tends to have this sort of problem), dead reckoning, educated guesses, staring at the code, and even on occasion brushing my teeth, going for a walk, or washing my hair. Getting the job done in spite of bad signal to noise ratio from tools is just part of the job description - for a very senior person. The SNR for flamegraphs is dropping, doubly so for junior and mid-level developers. And as I said in another thread a few days ago, we're also hiding data in 'modern' perf tools, which indicates to me that even the tool writers are missing some tricks. These days it's just easier to bump the cluster size from 18 to 21 machines and move on.