On Thu, Apr 13, 2017 at 8:51 AM, Zoltán Herczeg <hzmester@???> wrote:
> Hi,
>
>>>>I did some basic performance benchmarks between v1 and v2 of PCRE.
>>>>Depending on whether we use git-grep or git-log v2 is 1% to 10% slower
>>>>than v1 when both use JIT.
>>>
>>> I would like to see the compilation flags for both pcre1 and pcre2? By default the library compiles without optimization options which has the same effect as -O0 option. This could be changed by setting up a CFLAGS value.
>>
>>I did some further performance testing and it turns out much of this
>>was just due to me not compiling with -O3. I pulled pcre & pcre2 from
>>latest svn, built them both with:
>>
>> CXXFLAGS=-O3 CFLAGS=-O3 ./configure --prefix=$PWD/inst --enable-jit
>>
>>And then linked git against those respective libraries, also compiled
>>with -O3. I also fixed the bug you mentioned with not sharing
>>pcre2_match_data_create_from_pattern(), that's now constructed when
>>the pattern is compiled. Thanks!
>>
>>I then patched git itself so it won't try to take a non-pcre path for
>>fixed patterns[1], and ran a basic grep benchmark[2]. This shows:
>>
>> s/iter extended basic pcre2 pcre1 fixed
>>extended 2.07 -- -0% -49% -50% -50%
>>basic 2.07 0% -- -49% -49% -50%
>>pcre2 1.05 97% 97% -- -0% -1%
>>pcre1 1.05 98% 98% 0% -- -0%
>>fixed 1.04 99% 99% 1% 0% --
>>
>>I.e. no difference in v1 & v2 anymore. The log case though shows pcre1
>>being 2% faster than pcre2:
>>
>> s/iter basic extended pcre2 pcre1 fixed
>>basic 6.28 -- -0% -16% -17% -18%
>>extended 6.27 0% -- -16% -17% -18%
>>pcre2 5.28 19% 19% -- -2% -3%
>>pcre1 5.19 21% 21% 2% -- -1%
>>fixed 5.13 23% 22% 3% 1% --
>
> before a match start pcre initializes a lot of local variables and checks arguments. This overhead is a bit more costly for pcre2 because it has more features. This fixed cost must be payed every time you call pcre2_match and it accumulates if you frequently call it ("log" matches frequently). Pcre/pcre2 provides a low-level JIT matcher function called pcre_jit_exec / pcre2_jit_match which has a lower overhead because it does not check arguments.
Thanks, I forgot to say that in my latest test I changed to calling
pcre_jit_exec...
> If you want to use JIT in production level please also consider using the JIT stack, because the default 32K stack is not enough for heavy recursions. It is easy to use it for single threaded applications since you only need to allocate a single jit stack (and store it in a global variable).
>
> pcre2_jit_stack_create / pcre2_jit_stack_assign / pcre2_jit_stack_free
...but wasn't allocating the stack for pcre2 like that, but only for
pcre1 (where I think it can't be avoided). Will do that & check how
that performs. Thanks again.
