On Sat, Apr 1, 2017 at 8:24 PM, Junio C Hamano <gits...@pobox.com> wrote: > Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > >> On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano <gits...@pobox.com> wrote: >>> Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: >>> >>>> That enables the new JIT support in pcre v2: >>>> >>>> s/iter rx fixed prx >>>> rx 2.19 -- -33% -44% >>>> fixed 1.47 49% -- -17% >>>> prx 1.22 79% 20% -- >>> >>> The numbers with JIT does look "interesting". >>> >>> I couldn't quite tell if there are major incompatibilities in the >>> regex language itself between two versions from their documentation, >>> but assuming that there isn't (modulo bugfixes and enhancements) and >>> assuming that we are going to use their standard matcher, it may be >>> OK to just use the newer one without linking both. >> >> There's no incompatibilities in the regex language itself (modulo bugs >> etc). So yeah, I'll prepare some patch to use v2. > > Just to make sure that we are on the same page. While I do not see > the need to link with both variants and allow users to choose > between them at runtime, I do not know if the whole world is ready > to drop pcre1 and use pcre2 (the latter of which has only been > around for a bit over two years). > > So we'd probably want to do > > (1) keep USE_LIBPCRE and enable v1 when set; > (2) add USE_LIBPCRE2 and enable v2 when set; > (3) make sure to error out when both are set. > > or something like that. It is tempting to allow us to say > > make USE_LIBPCRE=2 > > but the existing builds are likely to be depending on "is it set to > anything? then use PCRE1" behaviour, so we unfortunately cannot take > that route.
We're on the same page, all of this makes sense, there'll be some OS's / environments which for years won't be packaging pcre2 but will have pcre1. I am very tempted though to support them in parallel, if only for ease of performance testing and to be able to roll out support for grep.patternType=perl meaning pcre1 for now, but add a grep.patternType=pcre2 for testing (and make grep.patternType=pcre1 work, with grep.patternType=pcre being synonymous with grep.patternType=perl, i.e. whatever the default is).
