Author: ph10 Date: To: pcunite CC: pcre-dev Subject: Re: [pcre-dev] New API for PCRE
On Sat, 29 Jun 2013, pcunite@??? wrote:
> I was referring to how match() uses recursion and can overflow the stack.
> It can use the heap but this is slower. I was hoping the new API removes
> the need for me to be concerned about this.
The new API is just that: a new API. There is no proposal to change the
way PCRE works internally (though I am planning to do some code tidying).
When PCRE is searching a large tree of possiblities, it needs memory
*somewhere* to remember the backtracking points. The interpretive
pcre_exec() function can, as you say, be compiled to use either the
stack or the heap. I don't think there's a third option. :-)
However:
(1) Setting the limit on recursion depth will be more straightforward in
the new API. This allows you to catch stack overflows.
(2) If you are in an environment that can use the JIT matcher instead of
the interpreter, much less stack is needed, though the JIT compiling
takes time. As of 8.33, the JIT supports all pattern features.
(3) It might be worth timing your kinds of pattern, using the stack and
the heap, to see how much difference there is in practice.
(4) When using the heap for storage, a custom memory manager for the
fixed-size blocks (e.g. keeping a chain of freed ones for re-use) might
also speed things up. The new API will have a thread-safe and more
flexible way of providing custom memory managers.
