Re: git grep performance regression on macOS

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 30, 2023, 05:45 UTC
Message-ID: <xmqqa5t4gqnd.fsf@gitster.g>
In-Reply-To: <CAPWWTaDE5559vA1qa0zhBid_ep9ht+PxPSDS5YC7Dk0NN8sp9A@mail.gmail.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.

Show 8 quoted lines

> 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.