On 11/16/2011 11:40 AM, Philip Hazel wrote:
On Wed, 16 Nov 2011, Sheri wrote:
Here's a minimal request, please let me know if feasible.
Suppose you added a regexec2 to the POSIX interface which passed study data
instead of NULL to pcre_exec. Couldn't the native pcre_study be used to create
study data based on the compiled pattern that was regcomp'ed? Mixed interface
for our older "global" regex'es?
Performance would be poor because every time you called regexec2, it
would have to do the study and the free ... and JIT study takes
appreciative resources. So unless you only ever match a pattern exactly
once, the performance gain might (would?) not be much, if anything. We
already know that for relatively simple patterns matched once, JIT is
not worth using. It comes into its own when you can do *one* JIT study,
followed by *many* calls to pcre_exec.
OK, now you are going to say why not do the study outside regexec, based
on the POSIX data structure generated by regcomp (i.e. invent regstudy).
If you do that, you have to pass it to regexec2 somehow ... this is
changing your code quite a lot: adding a call to regstudy, modifying
the regexec calls. I would argue that this is almost as much work as
changing to the native API.
I appreciate your situation, not a nice place to be in.
Philip
Thanks, I'll take your word for it. I thought the structure for a
pattern compiled with regcomp was the same as one compiled with
pcre_compile and could be passed as-is to pcre_study. Oh well. There are
no external options used with the patterns if that makes any difference.
The change on our side as I had pictured it was to add (inside our
global matchG and replaceG functions) a call to pcre_study before
repeated calls to regexec2 (with arg specified for extra data from
pcre_study), eventually followed by existing regfree and added
pcre_study_free.
Regards,
Sheri
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
