3 ms·

Is this for educational purposes or for production-grade code? Because you can take CPU profiles to create flame graphs to show stack depth and examine how muc

Is this for educational purposes or for production-grade code? Because you can take CPU profiles to create flame graphs to show stack depth and examine how much time is spent in different stack frames. You can also run via node --inspect program.js to connect the chrome dev tools and take CPU profiles / heap snapshots that way. I've run into a few issues doing this but they might be too niche for whatever it is you're doing: 1. Platform compatibility sucks. I think you can use perf on Linux or dtrace on OSX. On Windows there's xperf but you run into issues when you need to run things in elevated CMD but you don't have access to do so (not an uncommon situation in enterprise environments). In the end I gave up going this route 2. With doing this via the Chrome dev tools, I couldn't find a way to persist a .cpusnapshot to disk and load it later in Chrome. I wanted to do it on disk first because the whole thing crashes on me if the CPU snapshot runs longer than X minutes, so if the browser crashes with the file from disk I could try running it with the stackvis package. Again I couldn't run with node --perf_basic_prof because it's not cross-platform I hope that helps.

kunalpatel73 9y ago
This is for educational purposes. Thanks for the tip on seeing how much time is spent on different stack frames. Your response has helped most definitely. However, we want to take a deeper dive and be able to access nested async functions. We would like be able to specifically identify each function, and the time spent to execute each function, whether it be async or a nested async function. This would help for debugging purposes to be able to see which function is taking a while to process. Do you find this to be a feasible idea?
- arenaninja 9y ago
  By "the time spent each function", how is that different from http://www.brendangregg.com/flamegraphs.html http://www.brendangregg.com/flamegraphs.html? The only thing I can think of is that typically the x axis in flamegraphs is sorted alphabetically and aggregated and you could instead try to do this chronologically and in isolation. I'm curious which workflows you think your approach would be well suited for. In my case, I was investigating a webpack build process and flamegraphs served me well because with over 2000 modules seeing the data in aggregate is actually helpful. Though if purely for educational purposes, you can always do this chronologically and focus on a subset if the running time is too long

kunalpatel73 9y ago

This is for educational purposes. Thanks for the tip on seeing how much time is spent on different stack frames. Your response has helped most definitely. However, we want to take a deeper dive and be able to access nested async functions. We would like be able to specifically identify each function, and the time spent to execute each function, whether it be async or a nested async function. This would help for debugging purposes to be able to see which function is taking a while to process. Do you find this to be a feasible idea?

arenaninja 9y ago
By "the time spent each function", how is that different from http://www.brendangregg.com/flamegraphs.html http://www.brendangregg.com/flamegraphs.html? The only thing I can think of is that typically the x axis in flamegraphs is sorted alphabetically and aggregated and you could instead try to do this chronologically and in isolation. I'm curious which workflows you think your approach would be well suited for. In my case, I was investigating a webpack build process and flamegraphs served me well because with over 2000 modules seeing the data in aggregate is actually helpful. Though if purely for educational purposes, you can always do this chronologically and focus on a subset if the running time is too long