2016-09-22 00:31:23 +02:00
|
|
|
# Copyright (c) 2015-2016 The Bitcoin Core developers
|
|
|
|
|
# Distributed under the MIT software license, see the accompanying
|
|
|
|
|
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
|
|
|
|
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
bin_PROGRAMS += bench/bench_bitcoin
|
|
|
|
|
BENCH_SRCDIR = bench
|
|
|
|
|
BENCH_BINARY = bench/bench_bitcoin$(EXEEXT)
|
|
|
|
|
|
2017-10-01 23:07:23 +02:00
|
|
|
RAW_BENCH_FILES = \
|
2016-06-01 10:39:56 +02:00
|
|
|
bench/data/block413567.raw
|
2017-10-01 23:07:23 +02:00
|
|
|
GENERATED_BENCH_FILES = $(RAW_BENCH_FILES:.raw=.raw.h)
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
|
|
|
|
|
bench_bench_bitcoin_SOURCES = \
|
2017-10-01 23:07:23 +02:00
|
|
|
$(RAW_BENCH_FILES) \
|
2020-04-20 17:10:52 +02:00
|
|
|
bench/addrman.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/base58.cpp \
|
|
|
|
|
bench/bech32.cpp \
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
bench/bench.cpp \
|
|
|
|
|
bench/bench.h \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/bench_bitcoin.cpp \
|
2023-04-18 18:16:45 +02:00
|
|
|
bench/bip324_ecdh.cpp \
|
2018-04-18 22:29:41 +02:00
|
|
|
bench/block_assemble.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/ccoins_caching.cpp \
|
|
|
|
|
bench/chacha20.cpp \
|
2016-06-01 10:39:56 +02:00
|
|
|
bench/checkblock.cpp \
|
2017-01-07 22:34:50 +01:00
|
|
|
bench/checkqueue.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/crypto_hash.cpp \
|
2019-07-01 22:42:22 +02:00
|
|
|
bench/data.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/data.h \
|
2019-05-29 07:32:42 +02:00
|
|
|
bench/descriptors.cpp \
|
2023-09-01 12:58:23 +02:00
|
|
|
bench/disconnected_transactions.cpp \
|
2018-10-04 08:09:19 +02:00
|
|
|
bench/duplicate_inputs.cpp \
|
2021-11-03 18:08:51 +01:00
|
|
|
bench/ellswift.cpp \
|
2018-05-23 14:14:58 +02:00
|
|
|
bench/examples.cpp \
|
2018-05-14 07:27:14 +02:00
|
|
|
bench/gcs_filter.cpp \
|
2019-07-24 22:36:47 +02:00
|
|
|
bench/hashpadding.cpp \
|
2023-11-25 16:10:52 +01:00
|
|
|
bench/index_blockfilter.cpp \
|
2022-10-24 20:10:45 +02:00
|
|
|
bench/load_external.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/lockedpool.cpp \
|
2020-04-29 15:05:41 +02:00
|
|
|
bench/logging.cpp \
|
2016-10-02 23:38:48 +02:00
|
|
|
bench/mempool_eviction.cpp \
|
2019-10-28 23:56:27 +01:00
|
|
|
bench/mempool_stress.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/merkle_root.cpp \
|
Replace current benchmarking framework with nanobench
This replaces the current benchmarking framework with nanobench [1], an
MIT licensed single-header benchmarking library, of which I am the
autor. This has in my opinion several advantages, especially on Linux:
* fast: Running all benchmarks takes ~6 seconds instead of 4m13s on
an Intel i7-8700 CPU @ 3.20GHz.
* accurate: I ran e.g. the benchmark for SipHash_32b 10 times and
calculate standard deviation / mean = coefficient of variation:
* 0.57% CV for old benchmarking framework
* 0.20% CV for nanobench
So the benchmark results with nanobench seem to vary less than with
the old framework.
* It automatically determines runtime based on clock precision, no need
to specify number of evaluations.
* measure instructions, cycles, branches, instructions per cycle,
branch misses (only Linux, when performance counters are available)
* output in markdown table format.
* Warn about unstable environment (frequency scaling, turbo, ...)
* For better profiling, it is possible to set the environment variable
NANOBENCH_ENDLESS to force endless running of a particular benchmark
without the need to recompile. This makes it to e.g. run "perf top"
and look at hotspots.
Here is an example copy & pasted from the terminal output:
| ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark
|--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:----------
| 2.52 | 396,529,415.94 | 0.6% | 25.42 | 8.02 | 3.169 | 0.06 | 0.0% | 0.03 | `bench/crypto_hash.cpp RIPEMD160`
| 1.87 | 535,161,444.83 | 0.3% | 21.36 | 5.95 | 3.589 | 0.06 | 0.0% | 0.02 | `bench/crypto_hash.cpp SHA1`
| 3.22 | 310,344,174.79 | 1.1% | 36.80 | 10.22 | 3.601 | 0.09 | 0.0% | 0.04 | `bench/crypto_hash.cpp SHA256`
| 2.01 | 496,375,796.23 | 0.0% | 18.72 | 6.43 | 2.911 | 0.01 | 1.0% | 0.00 | `bench/crypto_hash.cpp SHA256D64_1024`
| 7.23 | 138,263,519.35 | 0.1% | 82.66 | 23.11 | 3.577 | 1.63 | 0.1% | 0.00 | `bench/crypto_hash.cpp SHA256_32b`
| 3.04 | 328,780,166.40 | 0.3% | 35.82 | 9.69 | 3.696 | 0.03 | 0.0% | 0.03 | `bench/crypto_hash.cpp SHA512`
[1] https://github.com/martinus/nanobench
* Adds support for asymptotes
This adds support to calculate asymptotic complexity of a benchmark.
This is similar to #17375, but currently only one asymptote is
supported, and I have added support in the benchmark `ComplexMemPool`
as an example.
Usage is e.g. like this:
```
./bench_bitcoin -filter=ComplexMemPool -asymptote=25,50,100,200,400,600,800
```
This runs the benchmark `ComplexMemPool` several times but with
different complexityN settings. The benchmark can extract that number
and use it accordingly. Here, it's used for `childTxs`. The output is
this:
| complexityN | ns/op | op/s | err% | ins/op | cyc/op | IPC | total | benchmark
|------------:|--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|----------:|:----------
| 25 | 1,064,241.00 | 939.64 | 1.4% | 3,960,279.00 | 2,829,708.00 | 1.400 | 0.01 | `ComplexMemPool`
| 50 | 1,579,530.00 | 633.10 | 1.0% | 6,231,810.00 | 4,412,674.00 | 1.412 | 0.02 | `ComplexMemPool`
| 100 | 4,022,774.00 | 248.58 | 0.6% | 16,544,406.00 | 11,889,535.00 | 1.392 | 0.04 | `ComplexMemPool`
| 200 | 15,390,986.00 | 64.97 | 0.2% | 63,904,254.00 | 47,731,705.00 | 1.339 | 0.17 | `ComplexMemPool`
| 400 | 69,394,711.00 | 14.41 | 0.1% | 272,602,461.00 | 219,014,691.00 | 1.245 | 0.76 | `ComplexMemPool`
| 600 | 168,977,165.00 | 5.92 | 0.1% | 639,108,082.00 | 535,316,887.00 | 1.194 | 1.86 | `ComplexMemPool`
| 800 | 310,109,077.00 | 3.22 | 0.1% |1,149,134,246.00 | 984,620,812.00 | 1.167 | 3.41 | `ComplexMemPool`
| coefficient | err% | complexity
|--------------:|-------:|------------
| 4.78486e-07 | 4.5% | O(n^2)
| 6.38557e-10 | 21.7% | O(n^3)
| 3.42338e-05 | 38.0% | O(n log n)
| 0.000313914 | 46.9% | O(n)
| 0.0129823 | 114.4% | O(log n)
| 0.0815055 | 133.8% | O(1)
The best fitting curve is O(n^2), so the algorithm seems to scale
quadratic with `childTxs` in the range 25 to 800.
2020-06-13 09:37:27 +02:00
|
|
|
bench/nanobench.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/nanobench.h \
|
2024-02-20 15:59:41 +01:00
|
|
|
bench/parse_hex.cpp \
|
2021-06-20 13:04:45 +02:00
|
|
|
bench/peer_eviction.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/poly1305.cpp \
|
2022-06-11 09:23:51 +02:00
|
|
|
bench/pool.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/prevector.cpp \
|
2023-08-07 16:15:26 +02:00
|
|
|
bench/readblock.cpp \
|
2020-04-29 15:13:14 +02:00
|
|
|
bench/rollingbloom.cpp \
|
2019-06-22 12:37:51 +02:00
|
|
|
bench/rpc_blockchain.cpp \
|
2019-02-23 17:11:14 +01:00
|
|
|
bench/rpc_mempool.cpp \
|
2020-08-10 20:28:28 +02:00
|
|
|
bench/streams_findbyte.cpp \
|
2022-03-23 07:43:58 +01:00
|
|
|
bench/strencodings.cpp \
|
2019-05-18 23:44:39 +02:00
|
|
|
bench/util_time.cpp \
|
2023-06-12 11:28:59 +02:00
|
|
|
bench/verify_script.cpp \
|
|
|
|
|
bench/xor.cpp
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
|
2017-10-01 23:07:23 +02:00
|
|
|
nodist_bench_bench_bitcoin_SOURCES = $(GENERATED_BENCH_FILES)
|
2016-06-01 10:39:56 +02:00
|
|
|
|
2022-09-09 18:55:21 +02:00
|
|
|
bench_bench_bitcoin_CPPFLAGS = $(AM_CPPFLAGS) $(BITCOIN_INCLUDES) $(BOOST_CPPFLAGS) $(EVENT_CFLAGS) $(EVENT_PTHREADS_CFLAGS) -I$(builddir)/bench/
|
2015-11-10 02:50:25 +01:00
|
|
|
bench_bench_bitcoin_CXXFLAGS = $(AM_CXXFLAGS) $(PIE_FLAGS)
|
2022-09-15 11:05:51 +02:00
|
|
|
bench_bench_bitcoin_LDFLAGS = $(RELDFLAGS) $(AM_LDFLAGS) $(LIBTOOL_APP_LDFLAGS) $(PTHREAD_FLAGS)
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
bench_bench_bitcoin_LDADD = \
|
2022-03-10 21:38:34 +01:00
|
|
|
$(LIBTEST_UTIL) \
|
2021-12-20 16:53:01 +01:00
|
|
|
$(LIBBITCOIN_NODE) \
|
2017-06-13 03:53:46 +02:00
|
|
|
$(LIBBITCOIN_WALLET) \
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
$(LIBBITCOIN_COMMON) \
|
|
|
|
|
$(LIBBITCOIN_UTIL) \
|
2015-11-20 16:46:03 +01:00
|
|
|
$(LIBBITCOIN_CONSENSUS) \
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
$(LIBBITCOIN_CRYPTO) \
|
|
|
|
|
$(LIBLEVELDB) \
|
|
|
|
|
$(LIBMEMENV) \
|
2016-01-31 03:32:55 +01:00
|
|
|
$(LIBSECP256K1) \
|
2019-02-23 17:11:14 +01:00
|
|
|
$(LIBUNIVALUE) \
|
|
|
|
|
$(EVENT_PTHREADS_LIBS) \
|
2022-09-15 11:05:51 +02:00
|
|
|
$(EVENT_LIBS) \
|
|
|
|
|
$(MINIUPNPC_LIBS) \
|
|
|
|
|
$(NATPMP_LIBS)
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
|
|
|
|
|
if ENABLE_ZMQ
|
|
|
|
|
bench_bench_bitcoin_LDADD += $(LIBBITCOIN_ZMQ) $(ZMQ_LIBS)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
if ENABLE_WALLET
|
2016-10-02 23:38:48 +02:00
|
|
|
bench_bench_bitcoin_SOURCES += bench/coin_selection.cpp
|
2019-04-10 21:06:31 +02:00
|
|
|
bench_bench_bitcoin_SOURCES += bench/wallet_balance.cpp
|
2023-11-16 15:15:08 +01:00
|
|
|
bench_bench_bitcoin_SOURCES += bench/wallet_create.cpp
|
2022-04-18 21:52:26 +02:00
|
|
|
bench_bench_bitcoin_SOURCES += bench/wallet_loading.cpp
|
2022-08-03 19:59:55 +02:00
|
|
|
bench_bench_bitcoin_SOURCES += bench/wallet_create_tx.cpp
|
2024-02-02 20:16:43 +01:00
|
|
|
bench_bench_bitcoin_SOURCES += bench/wallet_ismine.cpp
|
|
|
|
|
|
2022-09-15 11:05:51 +02:00
|
|
|
bench_bench_bitcoin_LDADD += $(BDB_LIBS) $(SQLITE_LIBS)
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
endif
|
|
|
|
|
|
2017-10-01 23:07:23 +02:00
|
|
|
CLEAN_BITCOIN_BENCH = bench/*.gcda bench/*.gcno $(GENERATED_BENCH_FILES)
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
|
|
|
|
|
CLEANFILES += $(CLEAN_BITCOIN_BENCH)
|
|
|
|
|
|
2019-07-01 22:42:22 +02:00
|
|
|
bench/data.cpp: bench/data/block413567.raw.h
|
2016-06-01 10:39:56 +02:00
|
|
|
|
Simple benchmarking framework
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
2015-09-24 19:13:38 +02:00
|
|
|
bitcoin_bench: $(BENCH_BINARY)
|
|
|
|
|
|
|
|
|
|
bench: $(BENCH_BINARY) FORCE
|
|
|
|
|
$(BENCH_BINARY)
|
|
|
|
|
|
|
|
|
|
bitcoin_bench_clean : FORCE
|
|
|
|
|
rm -f $(CLEAN_BITCOIN_BENCH) $(bench_bench_bitcoin_OBJECTS) $(BENCH_BINARY)
|