4 ms·
By looking at the benchmarks, it is interesting to see how much an advantage have non-backtracking engines versus the default Java one. It is also interesting t
by kamma4434 2y ago
By looking at the benchmarks, it is interesting to see how much an advantage have non-backtracking engines versus the default Java one. It is also interesting that most of the regular expressions I happen to write are not backtracking, so it’s likely I’m paying a ticket every time for a feature I’m not going to see.
It would be interesting if the default Java class the implements regular expressions would detect whether backtracking is actually used in the regular expression when it is compiled and decide whether the full blown engine is really necessary or a lightweight one would be enough.
- burntsushi 2y agoThe set of regex engines being compared here is pretty small, and even among backtracking regex engines, Java's is pretty slow. See: https://github.com/BurntSushi/rebar?tab=readme-ov-file#summary-of-search-time-benchmarks https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa... The backtracking engines ahead of are pcre2/jit, javascript/v8, d/ldc/std-regex (technically a hybrid I believe) and regress. Java's engine is about on par with Python's and Perl's (which are both written in C).
- hyperpape 2y agoI’d definitely like to get needle into rebar (or a branch of it) and be able to run a broader set of comparisons. Also, I’ve learned a lot from your code. A lot of this project was stubbornly banging my head against the problem, but whenever I wanted to see how another engine did things, your library was the one I looked at.
- burntsushi 2y agoYeah! Please file issues or ask questions if you need help. :-) Hopefully it's easy enough to follow the `java` example to add your own.