You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I have done many times before, I decided to test the Profile-Guided Optimization (PGO) technique to optimize the library performance. For reference, results for other projects are available at https://github.com/zamazan4ik/awesome-pgo . Since PGO helped a lot for many libraries and projects in the database domain, I decided to apply it to canopydb to see if the performance win (or lose) can be achieved. Here are my benchmark results.
This information can be interesting for anyone who wants to achieve more performance with the library in their use cases.
Test environment
Fedora 40
Linux kernel 6.10.12
AMD Ryzen 9 5900x
48 Gib RAM
SSD Samsung 980 Pro 2 Tib
Compiler - Rustc 1.82.0
canopydb version: used in the benchmark (see details below)
Disabled Turbo boost
Benchmark
For benchmark purposes, I use this benchmark method. For PGO optimization I use cargo-pgo tool. PGO training dataset for all benchmarks is the same - the benchmark itself (so three training datasets since I performed 3 benches). All measurements are done on the same machine, with the same background "noise" (as much as I can guarantee).
A note about the results for RocksDB. cargo-pgo doesn't by default apply PGO optimization to C++ dependencies. However, PGO results for RocksDB are also available in the "awesome-pgo" repo.
According to the results in the benchmarks above, we see performance improvements in many cases (not only for canopydb btw!).
Further steps
At the very least, the library's users can find this performance report and decide to enable PGO for their applications if they care about canopydb performance in their workloads. Maybe a small note somewhere in the documentation (the README file?) will be enough to raise awareness about this work.
Also, Post-Link Optimization (PLO) can be tested after PGO. It can be done by applying tools like LLVM BOLT to applications with apps that use canopydb. However, it's a much less mature optimization technique compared to PGO.
Thank you.
P.S. It's just a benchmark report, not a bug. Probably Discussions is a better place to put such things but they are disabled for the repo for now.
The text was updated successfully, but these errors were encountered:
Hi!
As I have done many times before, I decided to test the Profile-Guided Optimization (PGO) technique to optimize the library performance. For reference, results for other projects are available at https://github.com/zamazan4ik/awesome-pgo . Since PGO helped a lot for many libraries and projects in the database domain, I decided to apply it to
canopydb
to see if the performance win (or lose) can be achieved. Here are my benchmark results.This information can be interesting for anyone who wants to achieve more performance with the library in their use cases.
Test environment
canopydb
version: used in the benchmark (see details below)Benchmark
For benchmark purposes, I use this benchmark method. For PGO optimization I use cargo-pgo tool. PGO training dataset for all benchmarks is the same - the benchmark itself (so three training datasets since I performed 3 benches). All measurements are done on the same machine, with the same background "noise" (as much as I can guarantee).
A note about the results for RocksDB.
cargo-pgo
doesn't by default apply PGO optimization to C++ dependencies. However, PGO results for RocksDB are also available in the "awesome-pgo" repo.Results
Here we go - the results!
large_values_benchmark
Release:
PGO optimized:
(just for reference) PGO instrumented:
int_benchmark
Release:
PGO optimized:
(just for reference) PGO instrumented:
lmdb_benchmark
Release:
PGO optimized:
(just for reference) PGO instrumented:
According to the results in the benchmarks above, we see performance improvements in many cases (not only for
canopydb
btw!).Further steps
At the very least, the library's users can find this performance report and decide to enable PGO for their applications if they care about
canopydb
performance in their workloads. Maybe a small note somewhere in the documentation (the README file?) will be enough to raise awareness about this work.Also, Post-Link Optimization (PLO) can be tested after PGO. It can be done by applying tools like LLVM BOLT to applications with apps that use
canopydb
. However, it's a much less mature optimization technique compared to PGO.Thank you.
P.S. It's just a benchmark report, not a bug. Probably Discussions is a better place to put such things but they are disabled for the repo for now.
The text was updated successfully, but these errors were encountered: