Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Support CPU profiling sections of code #3971
Signed-off-by: Breezewish email@example.com
What have you changed? (mandatory)
We usually need to find out why specific sections of code are slow. However, sometimes it cannot be done via simple perf, i.e. when there is a bootstrap. This PR provides facility to programmatically start or stop CPU profiling. In this way, we can start profiling before our interested code begins and stop profiling after it ends.
We can explore more interesting usages in the future, i.e. toggle profiling dynamically via signals, or environment variables. Future PRs are welcome!
The manual is in the code. I paste it here for easy reading:
Profile a part of the code using CPU Profiler from gperftools or Callgrind.
profiler::start("./app.profile"); some_complex_code(); profiler::stop();
Then, compile the code with
By default, a profile called
If the application is running in Callgrind, a Callgrind profile dump will be generated instead.
TIKV_PROFILE=1 valgrind --tool=callgrind --instr-atstart=no ./my_example
This is very cool @breeswish.
I guess that the idea is to insert start and stop temporarily and then remove them when done? Otherwise there's a lot of deadlock potential.
One nice change would be to change the profiler manifest to make all the dependencies optional (particularly the profiling deps), and have the
Is there anything holding up landing this?
Maybe docs - like the allocator configuration this seems like something that should be surfaced in a developer's guide. Not necessary for this PR though.
Yes. A better way maybe, provide interfaces to trigger a start and stop it moment later so that a profile can be generated. This does not introduce runtime costs when profiling is not started. The interface can be our status server like #4444
Nop, it's just lack of reviewers previously :)