For long running RE's in a web cache daemon I think it would be crazy not to always call the JIT, eh? Unless using DFA mode or something.
Matthew
--
Sent from my mobile device.
On September 29, 2014 9:21:57 AM PDT, ph10@??? wrote:
>On Mon, 29 Sep 2014, Nils Goroll wrote:
>
>> https://www.varnish-cache.org/ uses pcre by compiling a domain
>language (VCL)
>> into C and I wonder if we can offer varnish users a way of
>dynamically enabling
>> JIT per RE.
>>
>> Obiously one could add some flag outside the RE, but I wonder if it
>would make
>> sense to add an option setting (like "(*JIT)") the the RE itself,
>which would
>> have the same effect as PCRE_STUDY_JIT_COMPILE when pcre_study() is
>called.
>>
>> There could be a PCRE_STUDY_JIT_OPTION flag to allow pcre_study to
>turn on JIT
>> dynamically. Callers would have to oblige to calling
>pcre_free_study() when
>> using PCRE_STUDY_JIT_OPTION.
>
>This is something that could be thought about in the context of the new
>
>API for PCRE that is being developed (known as PCRE2). Preliminary code
>is already available for brave people who like testing things at
>
>svn co svn://vcs.exim.org/pcre2/code/trunk pcre2
>
>I am currently working on the documentation. Interpretive matching is
>working, but JIT has yet to be implemented (though I have just
>documented it :-).
>
>In the new API, there is no longer an explicit "study" function - as it
>turned out to be cheap, it now always done. For JIT there will be a new
>function called pcre2_jit_compile(), to be called after pcre2_compile()
>has been successful. Freeing of the JIT memory will happen
>automatically
>when pcre2_code_free() is called.
>
>It would be relatively simple to add support for (*JIT) to PCRE2. It is
>
>unlikely that new developments such as this will now be added to PCRE1.
>
>However, I am slightly wondering why you need to offer the option to
>varnish users rather than just enabling JIT always, in order to get the
>
>fastest performance. What have I missed?
>
>Philip
