-Patterns are compiled by PCRE into a reasonably efficient byte code, so that -most simple patterns do not use much memory. However, there is one case where -the memory usage of a compiled pattern can be unexpectedly large. If a +Patterns are compiled by PCRE into a reasonably efficient interpretive code, so +that most simple patterns do not use much memory. However, there is one case +where the memory usage of a compiled pattern can be unexpectedly large. If a parenthesized subpattern has a quantifier with a minimum greater than 1 and/or a limited maximum, the whole subpattern is repeated in the compiled code. For example, the pattern @@ -48,12 +48,12 @@ example, the very simple pattern
((ab){1,1000}c){1,3}
-uses 51K bytes when compiled. When PCRE is compiled with its default internal
-pointer size of two bytes, the size limit on a compiled pattern is 64K, and
-this is reached with the above pattern if the outer repetition is increased
-from 3 to 4. PCRE can be compiled to use larger internal pointers and thus
-handle larger compiled patterns, but it is better to try to rewrite your
-pattern to use less memory if you can.
+uses 51K bytes when compiled using the 8-bit library. When PCRE is compiled
+with its default internal pointer size of two bytes, the size limit on a
+compiled pattern is 64K data units, and this is reached with the above pattern
+if the outer repetition is increased from 3 to 4. PCRE can be compiled to use
+larger internal pointers and thus handle larger compiled patterns, but it is
+better to try to rewrite your pattern to use less memory if you can.
One way of reducing the memory usage for such patterns is to make use of PCRE's
@@ -77,11 +77,11 @@ that PCRE cannot otherwise handle.
STACK USAGE AT RUN TIME
-When pcre_exec() is used for matching, certain kinds of pattern can cause -it to use large amounts of the process stack. In some environments the default -process stack is quite small, and if it runs out the result is often SIGSEGV. -This issue is probably the most frequently raised problem with PCRE. Rewriting -your pattern can often help. The +When pcre_exec() or pcre16_exec() is used for matching, certain +kinds of pattern can cause it to use large amounts of the process stack. In +some environments the default process stack is quite small, and if it runs out +the result is often SIGSEGV. This issue is probably the most frequently raised +problem with PCRE. Rewriting your pattern can often help. The pcrestack documentation discusses this issue in detail.
@@ -110,8 +110,9 @@ character classes such as [:alpha:] do not use Unicode backwards compatibility, and partly for performance reasons. However, you can set PCRE_UCP if you want Unicode character properties to be used. This can double the matching time for items such as \d, when matched with -pcre_exec(); the performance loss is less with pcre_dfa_exec(), and -in both cases there is not much difference for \b. +a traditional matching function; the performance loss is less with +a DFA matching function, and in both cases there is not much difference for +\b.
When a pattern begins with .* not in parentheses, or in parentheses that are
@@ -186,9 +187,9 @@ Cambridge CB2 3QH, England.
REVISION
-Last updated: 16 May 2010
+Last updated: 09 January 2012
-Copyright © 1997-2010 University of Cambridge.
+Copyright © 1997-2012 University of Cambridge.
Return to the PCRE index page.