New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pool based memory resource #25325
Add pool based memory resource #25325
Conversation
6de57f7
to
d3c437f
Compare
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
850fe38
to
ba38016
Compare
6932541
to
b56c223
Compare
98bb268
to
d196da1
Compare
d196da1
to
9205b60
Compare
rebased to 9205b60 with minor fixes in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice review work, @LarryRuane.
re-ACK 9f947fc
ACK 9f947fc |
re-ACK 9f947fc |
Posthumous utACK 9f947fc |
Wohoo 🎉 Thanks everyone for making this happen! |
A memory resource similar to
std::pmr::unsynchronized_pool_resource
, but optimized for node-based containers. The goal is to be able to cache more coins with the same memory usage, and allocate/deallocate faster.This is a reimplementation of #22702. The goal was to implement it in a way that is simpler to review & test
There is now a generic
PoolResource
for allocating/deallocating memory. This has practically the same API asstd::pmr::memory_resource
. (Unfortunately I cannot use std::pmr because libc++ simply doesn't implement that API).Thanks to sipa there is now a fuzzer for PoolResource! On a fast machine I ran it for ~770 million executions without finding any issue.
The estimation of the correct node size is now gone, PoolResource now has multiple pools and just needs to be created large enough to have space for the unordered_map nodes.
I ran benchmarks with #22702, mergebase, and this PR. Frequency locked Intel i7-8700, clang++ 13.0.1 to reindex up to block 690000.
The performance is practically identical with #22702, just 0.4% slower. It's ~21% faster than master:
Note that on cache drops mergebase's memory doesnt go so far down because it does not free the
CCoinsMap
bucket array.