What is the advantage over Chrome dev tools' profiler?

[Shahor]

I don't know where else to ask, so hopefully this is ok to post here :)

I don't understand exactly what the advantage of this project (or 0x for that matter) is over Chrome's profiler, would you care to elaborate?

Cheers

[alsuren]

I use this tool because it fits into the workflow that I'm used to with flamegraph.pl in other languages. Specifically:

• Run your whole program under a sampling profiler at ~production speed.
• Post-process your output into a flamegraph.
• Modify your code and re-run, keeping the flamegraphs open in tabs next to each other for easy ctrl-tab based comparison to make sure you've improved the things that you were working on.

The reproducibility of the above workflow is something that is missing in the chrome://inspect workflow. When using the chrome://inspect workflow, the best I have managed is:

• node --inspect $script (which pauses the script until you've attached your GUI debugger)
• Attach your debugger.
• Click the "start profiling" button as quickly as possible, because anything that happens in that gap won't show up in your profile.
• If you somehow manage to get two traces that both contain the function you're trying to profile, you then need to struggle to zoom the chart view to the same width for the before/after runs for comparison.

I will admit that I currently have the Heavy (Bottom Up) view open in chrome devtools currently, but that's because I'm trying to find places to optimise in a recursive tree-walking algorithm (in babel) and this isn't something that you can easily visualise with flamegraphs. If I could find a way to convert isolate-*-v8.log into the format that devtools expects (Can't load file. Supported file extensions: '.cpuprofile'.) I might use chrome devtools more.

[Shahor]

Thanks for the detailed explanation :)

You might want to look into --inspect-brk though for node :)