Trait regex_automata::meta::strategy::Strategy
source · pub(super) trait Strategy: Debug + Send + Sync + RefUnwindSafe + UnwindSafe + 'static {
// Required methods
fn group_info(&self) -> &GroupInfo;
fn create_cache(&self) -> Cache;
fn reset_cache(&self, cache: &mut Cache);
fn is_accelerated(&self) -> bool;
fn memory_usage(&self) -> usize;
fn search(&self, cache: &mut Cache, input: &Input<'_>) -> Option<Match>;
fn search_half(
&self,
cache: &mut Cache,
input: &Input<'_>,
) -> Option<HalfMatch>;
fn is_match(&self, cache: &mut Cache, input: &Input<'_>) -> bool;
fn search_slots(
&self,
cache: &mut Cache,
input: &Input<'_>,
slots: &mut [Option<NonMaxUsize>],
) -> Option<PatternID>;
fn which_overlapping_matches(
&self,
cache: &mut Cache,
input: &Input<'_>,
patset: &mut PatternSet,
);
}Expand description
A trait that represents a single meta strategy. Its main utility is in providing a way to do dynamic dispatch over a few choices.
Why dynamic dispatch? I actually don’t have a super compelling reason, and importantly, I have not benchmarked it with the main alternative: an enum. I went with dynamic dispatch initially because the regex engine search code really can’t be inlined into caller code in most cases because it’s just too big. In other words, it is already expected that every regex search will entail at least the cost of a function call.
I do wonder whether using enums would result in better codegen overall though. It’s a worthwhile experiment to try. Probably the most interesting benchmark to run in such a case would be one with a high match count. That is, a benchmark to test the overall latency of a search call.