Performance impact from perf context with PerfLevel::kDisable
- Dominant language
- C++
- Stars
- 32.1k
- Forks
- 6.9k
- Avg merge
- 32m
- Merged PRs (30d)
- 1
Description
I don't consider this to be a bug but I am curious whether we can reduce the perf context overhead.
I ran tools/benchmark.sh for v6.26.1 with PerfLevel::kDisable (code compiled, but perf context not used) and compared it with v6.26.1 with perf context code disabled at compile time . I will refer to these as v6.26.pc (perf context compiled but not used) and v6.26.nopc (perf context not compiled).
The overhead for compiling with the perf context code was ~5% to ~10% for write-heavy tests (fillseq, overwrite). The overhead was frequently close to zero for other tests although in some cases it reaches ~4%.
I was curious about this after seeing this code:
```
void InstrumentedMutex::Lock() {
PERF_CONDITIONAL_TIMER_FOR_MUTEX_GUARD(
db_mutex_lock_nanos, stats_code_ == DB_MUTEX_WAIT_MICROS,
stats_for_report(clock_, stats_), stats_code_);
LockInternal();
}
```
Which uses this macro, so there is a stack allocated object, a ctor and dtor for that object and a branch (the "if (condition)" below) added to the ::Lock path. Although I have yet to learn whether that is the source of the overhead.
```
#define PERF_CONDITIONAL_TIMER_FOR_MUTEX_GUARD(metric, condition, stats, \
ticker_type) \
PerfStepTimer perf_step_timer_##metric(&(perf_context.metric), nullptr, \
false, PerfLevel::kEnableTime, stats, \
ticker_type); \
if (condition) { \
perf_step_timer_##metric.Start(); \
}
```
The compilation command lines are:
`
DISABLE_WARNING_AS_ERROR=1 DEBUG_LEVEL=0 make V=1 VERBOSE=1 -j16 static_lib db_bench
EXTRA_CXXFLAGS="-DNPERF_CONTEXT" DISABLE_WARNING_AS_ERROR=1 DEBUG_LEVEL=0 make V=1 VERBOSE=1 -j16 static_lib db_bench
`
Contributor guide
Assessment
This issue has not been assessed yet.