On Sat, 29 Jun 2013, [email protected] 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. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
