This is a feature that several people have brought up. The idea would be to spawn a Ruby process directly and start profiling it. So instead of having to do this
# in one terminal or in the background
$ bundler run my_ruby_app
$ rbperf record --pid `pidof my_ruby_app` cpu
We could do
$ rbperf record --exec 'bundler run my_ruby_app' cpu
Possible implementation
This feature needs to control the execution of another process so the ptrace(2) system call is a good fit.
Something that this implementation might have to handle is the race condition between the moment when the process is executed and when all the libraries have been mapped in memory as there's a window when libruby, in the case of dynamically compiled CRuby, might not be mapped into memory yet, and we would have to fail to find the global data that rbperf needs to read
Summary
This is a feature that several people have brought up. The idea would be to spawn a Ruby process directly and start profiling it. So instead of having to do this
We could do
Possible implementation
This feature needs to control the execution of another process so the
ptrace(2)system call is a good fit.Something that this implementation might have to handle is the race condition between the moment when the process is executed and when all the libraries have been mapped in memory as there's a window when libruby, in the case of dynamically compiled CRuby, might not be mapped into memory yet, and we would have to fail to find the global data that rbperf needs to read
https://github.com/javierhonduco/rbperf/blob/48ce25b2db9e88553dfdf7d3136933ee580c2294/src/process.rs#L73-L76