Age | Commit message (Collapse) | Author |
|
|
|
45a5aaf Only call clear on prevector if it isn't trivially destructible and don't loop in clear (Jeremy Rubin)
aaa02e7 Add prevector destructor benchmark (Jeremy Rubin)
Tree-SHA512: 52bc8163b65b71310252f2d578349d0ddc364a6c23795c5e06e101f5449f04c96cbdca41c0cffb1974b984b8e33006471137d92b8dd4a81a98e922610a94132a
|
|
|
|
|
|
This adds cycle min/max/avg to the statistics.
Supported on x86 and x86_64 (natively through rdtsc), as well as Linux
(perf syscall).
|
|
Also removes generation of headers for *.raw files in test_bitcoin (none exist anymore)
|
|
|
|
|
|
The new benchmarks exercise script validation, CCoinsDBView caching,
mempool eviction, and wallet coin selection code.
All of the benchmarks added here are extremely simple and don't
necessarily mirror common real world conditions or interesting
performance edge cases. Details about how specific benchmarks can be
improved are noted in comments.
Github-Issue: #7883
|
|
|
|
|
|
Add benchmarks for the cryptographic hash algorithms:
- RIPEMD160
- SHA1
- SHA256
- SHA512
Continues work on #7883.
|
|
|
|
42407ed build-unix: Update UniValue build conditions (Luke Dashjr)
cdcad9f LDADD dependency order shuffling (Luke Dashjr)
62f7f2e Bugfix: Always include univalue in DIST_SUBDIRS (Luke Dashjr)
2356515 Change default configure option --with-system-univalue to "no" (Luke Dashjr)
5d3b29b doc: Add UniValue to build instructions (Luke Dashjr)
ab22705 Build against system UniValue when available (Luke Dashjr)
2adf7e2 Bugfix: The var is LIBUNIVALUE,not LIBBITCOIN_UNIVALUE (Luke Dashjr)
|
|
|
|
|
|
|
|
This allows for fPIE to be used selectively.
|
|
Avoid calling gettimeofday every time through the benchmarking loop, by keeping
track of how long each loop takes and doubling the number of iterations done
between time checks when they take less than 1/16'th of the total elapsed time.
|
|
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
|