Lines Matching refs:DFA

101 *during search*. For example, when executing a DFA, its states are computed
153 leftmost-first match. It can use the DFA matcher for this, but must run it
161 spend a lot of time shuffling states around. The DFA limits the performance hit
203 ## Unicode word boundaries may prevent the DFA from being used
208 It's a sad state of the current implementation. At the moment, the DFA will try
210 If the DFA comes across any non-ASCII byte, it will quit and fall back to an
216 expression. Even though the DFA may not be used, specialized routines will
223 can be transformed into a regex that uses the DFA with `(?-u:\b).+(?-u:\b)`. It
230 boundary in the first place, since the DFA will speculatively interpret it as
232 boundary is used explicitly, then the DFA won't quit in the presence of
239 ## Excessive counting can lead to exponential state blow up in the DFA
241 **Advice**: Don't write regexes that cause DFA state blow up if you care about
245 Well, it turns out that the process of converting an NFA to a DFA can lead to
249 1. The DFA is computed lazily. That is, a state in the DFA only exists in
250    memory if it is visited. In particular, the lazy DFA guarantees that *at
256    exorbitant memory usage. To ameliorate this, the DFA bounds the number of
259    too frequently, then the DFA will give up and execution will fall back to
268 In the future, it may be possible to increase the bound that the DFA uses,