On 22 September 2012 12:43, Zoltán Herczeg <[email protected]> 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.? Cheers, -- Giuseppe D'Angelo -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
