Author: Giuseppe D'Angelo Date: To: Zoltán Herczeg CC: pcre-dev Subject: Re: [pcre-dev] A native pcre exec for JIT
On 22 September 2012 12:43, Zoltán Herczeg <hzmester@???> wrote: > Dear devs,
>
> I have been thinking for some time, that the point of JIT is offering outstanding pattern matching performance (and it improved a lot lately) and it is still used through pcre_exec. So I am planning the add a new interface for JIT only:
>
> int pcre[16]_jit_exec(const pcre_extra *extra_data, PCRE_SPTR subject, int length, int start_offset, int options, int *offsets, int offsetcount, pcre_jit_stack *stack)
>
> Basically it is the same as pcre[16]_exec, excapt that re is removed and a jit stack argument is added. The interface of JIT is stable now, and I don't think it will be change much in the future.
>
> The purpose of this function is offering a faster execution speed by skipping checks. I.e. it does not check that the input is valid UTF, and the pointers are non-NULL, JIT compilation is successful. Since the jit stack is directly passed (and a mandatory argument!) the JIT callback is not used as well (much better for multithreaded software). This is suitable for software, which require high-performance matching speed, and all arguments are known to be valid, since they were checked before. These checks are mainly for avoiding software bugs, and these "debug" features are not needed for production ready, high-performance software. Other than skipping checks, it operates in the same way as pcre_exec. The new interface requires about 33% less time than pcre_exec.
I'm obviously in favour of a change which will improve matching speed :)
But out of curiosity, how come that pcre_exec can't just do what this
function is supposed to do when it has a JIT-compiled pattern, UTF
checks are not requested, etc.?
