Don't reallocate pcre2_match_data for every exec, you just need it once in comp #18
Conversation
This enables us to carry around more info around with our pattern, to come in the next commit.
As pointed out in a mailing list thread on pcre-dev[1] the match data should be allocated once per pattern and reused for each match, not allocated N times for each exec. I haven't benchmarked things but this doubtless speeds things up. 1. https://lists.exim.org/lurker/message/20170410.141338.5219e80f.en.html
|
Yes, this is how we should do it. We also need a 2nd compiled pcre2_code in pprivate for ascii/utf8 matches. The compiler doesn't know if the pattern will be used in ascii or utf8 context, so it will make a guess, and recompile if the code is missing. See #15 |
|
See the match-data-comp-alloc branch, and #19 |
|
@rurban Yeah no idea what that regression is about. FWIW I tested this on 5.14.0, ancient, I know. I don't have time to debug this, just hacked this up since it seemed like an easy win. So just closing this request since it has a regression, but maybe the idea can be salvaged in some other form. |
|
On a closer look this seems to be a general issue with re::engine::PCRE2's bugs related to mixed UTF8 & non-UTF8 patterns. Maybe it's worth merging this after all, since there's still a bunch of regressions related to that, and this one extra failure will be fixed when the general bug is fixed, i.e. we'll have both UTF-8 & non-UTF-8 pattern & match data in the pprivate struct & switch between them in some cases. |
|
I keep it as proper branch, and I'm investigating. Strange side effect. |
|
Yes, most likely. I'm looking into how study is implemented today |
See the linked mailing list thread on the second patch. This presumably makes things faster, maybe my use of malloc/free here should be amended to use some xmalloc/perl malloc function.