Skip to content

Commit 67d9990

Browse files
committed
make SaltedOutpointHasher noexcept
If the hash is not noexcept, unorderd_map has to assume that it can throw an exception. Thus when rehashing care needs to be taken. libstdc++ solves this by simply caching the hash value, which increases memory of each node by 8 bytes. Adding noexcept prevents this caching. In my experiments with -reindex-chainstate -stopatheight=594000, memory usage has decreased by 9.4% while runtime has increased by 1.6% due to additional hashing. Additionally, memusage::DynamicUsage() is now more accurate and does not underestimate.
1 parent 742cd77 commit 67d9990

File tree

1 file changed

+9
-1
lines changed

1 file changed

+9
-1
lines changed

src/coins.h

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -95,8 +95,16 @@ class SaltedOutpointHasher
9595
* This *must* return size_t. With Boost 1.46 on 32-bit systems the
9696
* unordered_map will behave unpredictably if the custom hasher returns a
9797
* uint64_t, resulting in failures when syncing the chain (#4634).
98+
*
99+
* Having the hash noexcept allows libstdc++'s unordered_map to recalculate
100+
* the hash during rehash, so it does not have to cache the value. This
101+
* reduces node's memory by sizeof(size_t). The required recalculation has
102+
* a slight performance penalty (around 1.6%), but this is compensated by
103+
* memory savings of about 9% which allow for a larger dbcache setting.
104+
*
105+
* @see https://gcc.gnu.org/onlinedocs/gcc-9.2.0/libstdc++/manual/manual/unordered_associative.html
98106
*/
99-
size_t operator()(const COutPoint& id) const {
107+
size_t operator()(const COutPoint& id) const noexcept {
100108
return SipHashUint256Extra(k0, k1, id.hash, id.n);
101109
}
102110
};

0 commit comments

Comments
 (0)