Is regex-automata's PatternID configurable

[masklinn]

I assume the pattern / PatternID feature of regex-automata is the underlying support for regex::RegexSet, however when there are a lot of non-trivial (non-literal) regexes RegexSet / new_many doesn't really work as (as far as I've been able to test) it builds a giant automaton which takes a huge amount of memory and is very slow. However in that case the patternid system is pretty much wasted.

Is there a way to build a regex_automaton::meta::Regex with a user-specified PatternID, in order to use that as payload? Or is it not actually reified but generated on the fly when matching the automaton?

[BurntSushi]

I assume the pattern / PatternID feature of regex-automata is the underlying support for regex::RegexSet, however when there are a lot of non-trivial (non-literal) regexes RegexSet / new_many doesn't really work as (as far as I've been able to test) it builds a giant automaton which takes a huge amount of memory and is very slow.

Yeah, it can indeed be quite slow. If you're willing to use more memory, you can set a higher dfa_size_limit which might help with search performance.

Is there a way to build a regex_automaton::meta::Regex with a user-specified PatternID, in order to use that as payload? Or is it not actually reified but generated on the fly when matching the automaton?

No there's no way for a user to provide their own PatternID. A PatternID is just the index of the pattern given to the constructor. I designed things this way because it's the interface with the lowest possible cost and with a predictable mapping. If regex-automata were to provide a user definable pattern ID abstraction, I don't think it would implement it any more efficiently than the caller layering their own pattern ID mapping on top of it. In particular, regex-automata doesn't necessarily treat a PatternID as just some opaque and arbitrary blob. It makes use the of the fact that it is a monotonically increasing integer starting from zero. That means that exposing a user facing abstraction over custom PatternIDs is probably a lot more complicated than you might imagine. (Or else regex-automata internals would need to be changed to make fewer assumptions, but that will probably come with some costs.)

So overall, your best bet is probably to maintain your own Map<CustomPatternID, PatternID> or similar. (I use Map<K, V> here in the generic abstract sense. I imagine it could be implemented via a Vec<PatternID> for example.)

[masklinn]

Fair enough, that's about what I thought but I figured I could always ask just in case.