Skip to content
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

Allow more optimizations with TermMatcher #154

Open
pchampin opened this issue Dec 13, 2023 · 1 comment
Open

Allow more optimizations with TermMatcher #154

pchampin opened this issue Dec 13, 2023 · 1 comment
Milestone

Comments

@pchampin
Copy link
Owner

pchampin commented Dec 13, 2023

This issue emerged from #153 .

The method TermMatcher::constant offers implementers a way to optimize their processing of TermMatchers: instead of naively generating all triples and filtering them using TermMatcher::matches, they can use the constant term to only generate the necessary triples.

This is very well for some implementations, but it makes it impossible to optimize on more complex matchers, which some implementations could do. It might be interesting to extend TermMatcher::constant into a more complex method(call it optimizationHint for example), which would return an enum as suggested below. Different implementations would be able to take advantage of different kinds of hints...

Proposal:

enum TermMatcherHint {
    NoHint, // you need to call  the match method...
    Constant(Term), // matches a unique term
    List(Vec[Term]), // matches a pre-determined list of terms
    Range(Term, Term) // matches any term in the given range (given some total order on terms)
    // ... anything else?
}

NB: Any would still return NoHint, and that's OK, because calling Any::match, which is implemented as { return true }, will be optimized away anyway.

@pchampin pchampin added this to the later milestone Dec 14, 2023
@pchampin
Copy link
Owner Author

pchampin commented Dec 18, 2023

NB: Any would still return NoHint, and that's OK, because calling Any::match, which is implemented as { return true }, will be optimized away anyway.

Rectification: Graph::triples_matching implementations will generally not need a specific hint for Any but implementations of MutableGraph::remove_matching and MutableGraph::retain_matching could benefit from such a hint.

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

No branches or pull requests

1 participant