Re: git grep performance regression on macOS

[Junio C Hamano <gitster@pobox.com>]

Benjamin Hiller <benhiller@gmail.com> writes:

> git grep seems to have gotten much slower as of git 2.39 on macOS for
> complex extended regexes.

> I confirmed that the performance regression was first introduced in
> 2.39. Additionally, I saw that reverting the change to Makefile from
> https://github.com/git/git/commit/1819ad327b7a1f19540a819813b70a0e8a7f798f
> fixed the performance regression and the git grep command went back to
> taking <1 second. That seems to indicate that switching from Git's
> regex library to the native macOS regex library caused this
> performance regression, but I haven't investigated beyond that to see
> why the native macOS regex library is so much slower.

Yeah, that does sound a plausible explanation.

The regexp code in compat/ is meant as a fallback implementation for
platforms whose regexp library lack certain features we take
advantage of, but it has a limitation that it is not unicode aware.
In the olden days, regexp library on macOS lacked REG_STARTEND
feature, which forced us to use NO_REGEX (hence the fallback
implementation we ship that is not unicode aware).  The commit you
cite makes us use the macOS native regexp library, as somebody on
the platform got annoyed enough by the lack of unicode awareness of
the fallback implementation, and also noticed that REG_STARTEND is
supported by the macOS native regexp library these days.

The change in 2.39 was unfortunately about correctness.  It would
have been nicer if macOS native implementation were faster, but use
of fallback implementation would be favoring "performance" (which
produces incorrect results "faster" when run with multi-byte
strings) over correctness, so it is not likely that a straight
reverting of the commit is a good idea.