On Tue, Apr 18, 2017 at 10:09 AM, Zoltán Herczeg <hzmes...@freemail.hu> wrote:
>>>>I.e. no difference in v1 & v2 anymore. The log case though shows pcre1
>>>>being 2% faster than pcre2:
>
> I don't know the reason then, needs more investigation. Btw I have started to
> improve the first character search optimization in JIT. It is still in
> progress (corner cases), although you can try it now.
I just tested against pcre1 & pcre2 trunk now with -O3 on both, and v2
is now ~20% faster than v1. I bisected it and it's because of your
recent SSE2 JIT optimizations. Thanks a lot.
The grep case now:
s/iter basic extended pcre1 fixed pcre2
basic 2.07 -- -0% -47% -50% -57%
extended 2.06 0% -- -47% -50% -57%
pcre1 1.10 88% 87% -- -6% -19%
fixed 1.04 99% 99% 6% -- -14%
pcre2 0.889 133% 132% 24% 17% --
And log:
s/iter extended basic pcre1 pcre2 fixed
extended 6.33 -- -0% -16% -17% -18%
basic 6.33 0% -- -16% -17% -18%
pcre1 5.29 20% 20% -- -0% -2%
pcre2 5.27 20% 20% 0% -- -2%
fixed 5.17 22% 22% 2% 2% --
>>...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.
>
> The JIT stack should not affect performance, its purpose is extending the
> memory available for JIT.
But doesn't that impact performance, or is the alternate case that the
pattern merely runs out and either errors out or falls back to a
slower non-JIT path? The relevant docs don't say, or maybe I'm missed
something.
Also, both stack_create & match_data_create optionally take
pcre2_general_context_create(), if I don't want to use my own custom
malloc/free is this something that's worth doing? The docs just say
you can do it, but don't suggest if it's worth it if you're not using
your own memory allocation.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
