On Thu, Apr 13, 2017 at 8:51 AM, Zoltán Herczeg <hzmes...@freemail.hu> 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.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
