Skip to content

Flat containers #498

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

Merged
merged 13 commits into from
Aug 13, 2025
Merged

Flat containers #498

merged 13 commits into from
Aug 13, 2025

Conversation

boocmp
Copy link
Collaborator

@boocmp boocmp commented Aug 11, 2025

This is a preparation PR for moving cosmetic filters into flatbuffers.

  1. Replaced FlatFilterMap with FlatMultiMapView - a common container that will also be used in CosmeticFilterCache
  2. Introduced FlatSetView (currently unused), which will be used in CosmeticFilterCache
  3. Moved flatbuffers utilities to a flatbuffers folder

@boocmp boocmp requested a review from atuchin-m August 11, 2025 12:20
@boocmp boocmp self-assigned this Aug 11, 2025
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust Benchmark

Benchmark suite Current: 82b6f4f Previous: d2e870c Ratio
rule-match-browserlike/brave-list 2272443061 ns/iter (± 8891407) 2218369928 ns/iter (± 12441920) 1.02
rule-match-first-request/brave-list 997270 ns/iter (± 14535) 993380 ns/iter (± 27500) 1.00
blocker_new/brave-list 151879453 ns/iter (± 3794682) 150901091 ns/iter (± 1059000) 1.01
blocker_new/brave-list-deserialize 68005495 ns/iter (± 2998873) 63992983 ns/iter (± 1761826) 1.06
memory-usage/brave-list-initial 16282069 ns/iter (± 3) 16225933 ns/iter (± 3) 1.00
memory-usage/brave-list-initial/max 64817658 ns/iter (± 3) 64817658 ns/iter (± 3) 1
memory-usage/brave-list-initial/alloc-count 1514486 ns/iter (± 3) 1514650 ns/iter (± 3) 1.00
memory-usage/brave-list-1000-requests 2516503 ns/iter (± 3) 2505592 ns/iter (± 3) 1.00
memory-usage/brave-list-1000-requests/alloc-count 66572 ns/iter (± 3) 66070 ns/iter (± 3) 1.01

This comment was automatically generated by workflow using github-action-benchmark.

github-actions[bot]

This comment was marked as outdated.

@boocmp boocmp marked this pull request as ready for review August 11, 2025 13:40
@boocmp boocmp requested a review from antonok-edm as a code owner August 11, 2025 13:40
@boocmp boocmp requested a review from atuchin-m August 12, 2025 10:27
@atuchin-m atuchin-m requested a review from Copilot August 12, 2025 18:27
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR refactors flatbuffers utilities to use common container implementations in preparation for moving cosmetic filters to flatbuffers. It replaces the existing FlatFilterMap with a more generic FlatMultiMapView that can be reused across different components.

  • Replaced FlatFilterMap with FlatMultiMapView - a more generic multimap container
  • Introduced FlatSetView (currently unused) for future use in CosmeticFilterCache
  • Moved flatbuffers utilities from filters module to dedicated flatbuffers module

Reviewed Changes

Copilot reviewed 18 out of 19 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
src/network_filter_list.rs Updated to use new FlatMultiMapView instead of FlatFilterMap
src/flatbuffers/ New module containing container implementations and utilities
src/filters/ Removed old flat_filter_map.rs and unsafe_tools.rs modules
tests/ Added comprehensive tests for new container implementations
Cargo.toml Added clippy lint allowance for format args

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Some(FlatMultiMapViewIterator {
index,
key,
keys: self.keys.clone(), // Cloning is 3-4% faster than & in benchmarks
Copy link
Preview

Copilot AI Aug 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] The comment claims cloning is faster than references, but this seems counterintuitive and may be a premature optimization. Consider providing more context about why cloning would be faster or benchmark conditions that led to this conclusion.

Suggested change
keys: self.keys.clone(), // Cloning is 3-4% faster than & in benchmarks
keys: self.keys.clone(), // Clone keys for iterator; see implementation details for performance considerations

Copilot uses AI. Check for mistakes.


impl<'a> PartitionPoint<'a, &str> for Vector<'a, ForwardsUOffset<&str>> {
fn lower_bound(&self, key: &&str) -> usize {
partition_point_fbvector(self, |x| *x < key)
Copy link
Preview

Copilot AI Aug 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parameter type &&str (double reference) is unusual and potentially confusing. Consider using &str instead to match the pattern of other implementations.

Suggested change
partition_point_fbvector(self, |x| *x < key)
fn lower_bound(&self, key: &str) -> usize {
partition_point_fbvector(self, |x| x < key)

Copilot uses AI. Check for mistakes.


impl<'a> PartitionPoint<'a, &str> for Vector<'a, ForwardsUOffset<&str>> {
fn lower_bound(&self, key: &&str) -> usize {
partition_point_fbvector(self, |x| *x < key)
Copy link
Preview

Copilot AI Aug 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comparison *x < key dereferences x which is already a &str, but key is &&str. This should be x < *key to compare &str with &str.

Suggested change
partition_point_fbvector(self, |x| *x < key)
partition_point_fbvector(self, |x| x < *key)

Copilot uses AI. Check for mistakes.

Copy link
Collaborator

@antonok-edm antonok-edm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved assuming the above are addressed

@@ -217,6 +217,7 @@ fn check_live_from_filterlists() {

#[cfg(feature = "resource-assembler")]
#[test]
#[ignore = "issues/499"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also fixed by #503, this test should not be ignored

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the bad thing that we have 2 branches now.
We fixed this into master, but this PR related only to 0.11.x.
I've manually cherry-picked and pushed #502 and #503 to 0.11.x to address this.

I believe we need to clarify our branching strategy here.

Comment on lines +6 to +9
/// A map-like container that uses flatbuffer references.
/// Provides O(log n) lookup time using binary search on the sorted index.
/// I is a key type, Keys is specific container of keys, &[I] for fast indexing (u32, u64)
/// and flatbuffers::Vector<I> if there is no conversion from Vector (str) to slice.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're accumulating several of these flatbuffer utility structs, I'm wondering if it makes sense to create and publish a new separate crate just for those? I imagine others in the Rust community could find them useful too.

No need to do so here, but something to consider.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be an option once we finally stabilize the interface and merge it to master.

@atuchin-m atuchin-m merged commit 45b0371 into 0.11.x Aug 13, 2025
7 checks passed
@atuchin-m atuchin-m deleted the flat_containers branch August 13, 2025 07:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants