-
Notifications
You must be signed in to change notification settings - Fork 117
perf(l1): avoid unnecesary work on bloom and keep a per layer bloom #5176
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
base: main
Are you sure you want to change the base?
Conversation
Keeping a per layer bloom helps avoiding rehashing every time a bloom rebuild happens. This is because the bloom merge method uses the u64 hash keys directly instead of rehashing the value of type T. This is an improved version of #5175 where in addition to that we keep a per layer bloom to avoid extra hash work.
Lines of code reportTotal lines added: Detailed view |
| /// Per layer bloom filter, None if the size was exceeded (exceedingly rare). | ||
| /// Having a bloom per layer avoids the cost of rehashing each key every time we rebuild the globam bloom, | ||
| /// since merge simply uses the u64 hashed keys instead of rehashing. | ||
| bloom: Option<qfilter::Filter>, |
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.
Don't change it right now, but I think we should start referring to this as "query filter", as we're not necessarily relying on the Bloom implementation (approximate query filter is the "generic" name, but too long).
Benchmark Block Execution Results Comparison Against Main
|
Keeping a per layer bloom helps avoiding rehashing every time a bloom rebuild happens.
This is because the bloom merge method uses the u64 hash keys directly instead of rehashing the value of type T.
This is an improved version of #5175 where in addition to that we keep a per layer bloom to avoid extra hash work.