Loading feed…
Planet MySQL0 Hot0 comments9 min read
PGO or not PGO this is the dilemma. Step 3
This final installment of a three-part series on Profile-Guided Optimization (PGO) for MySQL/Percona Server explains why a sysbench-tpcc-trained PGO build ended up slower than a plain -O3 build, and how to fix the training methodology. Three compounding problems are identified: narrow sysbench training pessimizes uncovered code paths (purge, flushing, error handling); high-concurrency instrumented runs corrupt GCC's non-atomic profile counters, requiring -fprofile-update=atomic; and instrumentation overhead distorts what counts as 'hot' under contention, causing the compiler to optimize lock-spinning code instead of real work. The fix is merging MTR's broad functional-path coverage with a moderate-concurrency (4-64 thread) sysbench run, since GCC automatically accumulates profile counts across training runs against the same instrumented binary. Even after this fix, gains remained small: 12% at low concurrency, shrinking to under 2% at high concurrency, with the concurrency-specific refinement contributing well under 1%. The conclusion is that PGO is not a clear-cut default to enable but a fragile, detail-sensitive optimization worth it only in a well-controlled build pipeline.
Source: https://www.percona.com/blog/pgo-or-not-pgo-this-is-the-dilemma-step-3. 8 Sync News only summarizes and links out; content copyright belongs to the authors and original sources.
Recommended for you
Bình luận
Đang tải bình luận…
