Decouple BlockFilter from GCS implementation#35158
Decouple BlockFilter from GCS implementation#35158rustaceanrob wants to merge 2 commits intobitcoin:masterfrom
BlockFilter from GCS implementation#35158Conversation
The `BlockFilter` type is coupled to GCS as the implementation of approximate set membership query. Callsites that query the block filter do not need to be aware of the underlying filter type. This commit introduces an opaque type of the properties a block filter has, and implements these properties for GCS. Any future filter type need only to implement this virtual class.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process. LLM Linter (✨ experimental)Possible typos and grammar issues:
2026-04-25 12:41:17 |
|
🚧 At least one of the CI tasks failed. HintsTry to run the tests locally, according to the documentation. However, a CI failure may still
Leave a comment here, if you need help tracking down a confusing failure. |
This commit allows for `BlockFilter` to hold any type that implements the properties of a block filter, rather than concretely holding a GCS filter.
8a64306 to
eff833c
Compare
| public: | ||
|
|
||
| BlockFilter() = default; | ||
| BlockFilter() : m_filter(std::make_unique<GCSFilter>()) {} |
There was a problem hiding this comment.
Question: LookupFilterRange() calls filters_out.resize(entries.size()), which now allocates a GCSFilter object for each default-constructed BlockFilter, only to have it immediately replaced by the filter read from disk.
Before this PR, default construction already allocated the encoded vector, so the extra allocation is probably small compared to disk I/O. Still, this looks like an added cost of having BlockFilter own the filter through the new abstraction. Is this a worthwhile trade-off given the extensibility goals here?
In researching potential additional block filter types, I found that
BlockFilteris coupled with the GCS implementation. Callers ofBlockFilter.GetFilterare interested inMatchandMatchAny, so new filter types may simply implement those two methods. This change allowsBlockFilterto hold arbitrary filter constructions while preserving how callers interact with block filters.