diff options
author | MarcoFalke <falke.marco@gmail.com> | 2018-12-12 14:30:21 -0500 |
---|---|---|
committer | MarcoFalke <falke.marco@gmail.com> | 2018-12-12 14:30:24 -0500 |
commit | 6d0a14703e288d72ff19d4d89defbc853233899f (patch) | |
tree | f32e9eecd1ce9c68a087b2cce4b3169fb9198e6d /libbitcoinconsensus.pc.in | |
parent | 38fb1b40dfb3fe18aad7de65bd5ac089f65a8612 (diff) | |
parent | 8db0c3d42b063118d17ab83ba8beeb3852f8fc6e (diff) |
Merge #14908: test: Removed implicit CTransaction constructor calls from tests and benchmarks.
8db0c3d42b Removed implicit CTransaction conversion from benchmaks (lucash-dev)
ed61abedb2 Removed implicit CTransaction constructor from tests (lucash-dev)
Pull request description:
This PR was split from #14906 and is a prerequisite for it.
It updates tests and benchmarks, removing all implicit calls to `CTransaction(CMutableTransaction&)` constructors. This will make possible making the constructor explicit in the next PR.
The original rationale for making the constructor explicit:
- Conversion constructors should not be explicit unless there's a strong reason for it (in the opinion of, for example, https://google.github.io/styleguide/cppguide.html, and https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ro-conversion. Let me know your take on this).
- This particular conversion is very costly -- it implies a serialization plus hash of the transaction.
- Even though `CTransaction` and `CMutableTransaction` represent the same data, they have very different use cases and performance properties.
- Making it explicit allows for easier reasoning of performance trade-offs.
- There has been previous performance issues caused by unneeded use of this implicit conversion.
- This PR creates a map for places to look for possible refactoring and performance gains (this benefit still holds if the PR is not merged).
Tree-SHA512: de8073aa6ff8a3153bcbe10818616677ecf9598e4978d8a0b4c39a262e71c36be5679cec08554c760d1f011ba6d37350318248eef15f6d9b86f9e4462b2de0d2
Diffstat (limited to 'libbitcoinconsensus.pc.in')
0 files changed, 0 insertions, 0 deletions