/ doc / benchmarking.md
benchmarking.md
 1  Benchmarking
 2  ============
 3  
 4  Bitcoin Core has an internal benchmarking framework, with benchmarks
 5  for cryptographic algorithms (e.g. SHA1, SHA256, SHA512, RIPEMD160, Poly1305, ChaCha20), rolling bloom filter, coins selection,
 6  thread queue, wallet balance.
 7  
 8  Running
 9  ---------------------
10  
11  For benchmarking, you only need to compile `bench_bitcoin`.  The bench runner
12  warns if you configure with `-DCMAKE_BUILD_TYPE=Debug`, but consider if building without
13  it will impact the benchmark(s) you are interested in by unlatching log printers
14  and lock analysis.
15  
16      cmake -B build -DBUILD_BENCH=ON
17      cmake --build build -t bench_bitcoin
18  
19  After compiling bitcoin-core, the benchmarks can be run with:
20  
21      build/bin/bench_bitcoin
22  
23  The output will look similar to:
24  ```
25  |               ns/op |                op/s |    err% |     total | benchmark
26  |--------------------:|--------------------:|--------:|----------:|:----------
27  |       57,927,463.00 |               17.26 |    3.6% |      0.66 | `AddrManAdd`
28  |          677,816.00 |            1,475.33 |    4.9% |      0.01 | `AddrManGetAddr`
29  
30  ...
31  
32  |             ns/byte |              byte/s |    err% |     total | benchmark
33  |--------------------:|--------------------:|--------:|----------:|:----------
34  |              127.32 |        7,854,302.69 |    0.3% |      0.00 | `Base58CheckEncode`
35  |               31.95 |       31,303,226.99 |    0.2% |      0.00 | `Base58Decode`
36  
37  ...
38  ```
39  
40  Help
41  ---------------------
42  
43      build/bin/bench_bitcoin -h
44  
45  To print the various options, like listing the benchmarks without running them
46  or using a regex filter to only run certain benchmarks.
47  
48  Notes
49  ---------------------
50  
51  Benchmarks help with monitoring for performance regressions and can act as a
52  scope for future performance improvements. They should cover components that
53  impact performance critical functions of the system. Functions are performance
54  critical if their performance impacts users and the cost associated with a
55  degradation in performance is high. A non-exhaustive list:
56  
57  - Initial block download (Cost: slow IBD results in full node operation being
58    less accessible)
59  - Block template creation (Cost: slow block template creation may result in
60    lower fee revenue for miners)
61  - Block propagation (Cost: slow block propagation may increase the rate of
62    orphaned blocks and mining centralization)
63  
64  A change aiming to improve the performance may be rejected when a clear
65  end-to-end performance improvement cannot be demonstrated. The change might
66  also be rejected if the code bloat or review/maintenance burden is too high to
67  justify the improvement.
68  
69  Benchmarks are ill-suited for testing denial-of-service issues as they are
70  restricted to the same input set (introducing bias). [Fuzz
71  tests](/doc/fuzzing.md) are better suited for this purpose, as they are
72  specifically aimed at exploring the possible input space.
73  
74  Going Further
75  --------------------
76  
77  To monitor Bitcoin Core performance more in depth (like reindex or IBD): https://github.com/bitcoin-dev-tools/benchcoin