bsdgrep(1): Add BSD_GREP_FASTMATCH option for removing fastmatch implementation

[kevans]

Summary

After dealing with weird cases and bugs in the fastmatch implementation (see: D10098, D10113), I sought to determine what benefit we were reaping from it.

My conclusion is that it is currently offering almost no benefit. When I disable BSD_GREP_FASTMATCH, leaving bsdgrep(1) to only use regex(3), I find the following:

• regex(3)'s performance with literal expressions offers a speed improvement over fastmatch
• regex(3)'s performance, both with simple BREs and EREs, seems to be comparable

This implementation was imported in r226035, and at the time it also offered little improvement. I think our efforts could be better spent by addressing issues in regex(3) rather than hunting down bad behavior exhibited in these parts.

This is the first step, offering BSD_GREP_FASTMATCH as an option to disable it so that we can appropriately assess the situation with and without it enabled and make a more informed decision.

Test Plan

Run kyua tests to ensure no regressions

[emaste]

I think this is generally a good idea. We can always improve the system regex.

[bdrewery]

Build system changes look good.

Can't this be a runtime option or env var check though?

[kevans]

In D10282#213119, @bdrewery wrote:

Can't this be a runtime option or env var check though?

It could be, but the end-goal here is to remove the option in the short to mid term along with everything included with it if it's deemed feasible -- probably following an exp-run[1] with the option off to make sure it doesn't break things further. This guarantees the fastmatch bits don't get used, and also clearly denotes exactly what I intend to remove when the option goes away. =)

[1] Separate exp-run, unless @emaste believes it a good idea to go ahead and include that in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218385

[bdrewery]

In D10282#213120, @kevans91_ksu.edu wrote:

In D10282#213119, @bdrewery wrote:

Can't this be a runtime option or env var check though?

It could be, but the end-goal here is to remove the option in the short to mid term along with everything included with it if it's deemed feasible -- probably following an exp-run[1] with the option off to make sure it doesn't break things further. This guarantees the fastmatch bits don't get used, and also clearly denotes exactly what I intend to remove when the option goes away. =)

[1] Separate exp-run, unless @emaste believes it a good idea to go ahead and include that in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218385

Makes sense, thanks!

[emaste]

usr.bin/grep/grep.c

720 ↗

(On Diff #27100)

Overly long line and extra tab.

[emaste]

tools/build/options/WITHOUT_BSD_GREP_FASTMATCH

3 ↗

(On Diff #27100)

.Xr 1 grep

and for now we should probably use the default installed name bsdgrep

4 ↗

(On Diff #27100)

.Xr 3 regex