1 files changed, 24 insertions, 17 deletions
diff --git a/doc/pcre2perform.3 b/doc/pcre2perform.3
index 8b49a2a..91ca22a 100644
--- a/doc/pcre2perform.3
+++ b/doc/pcre2perform.3
@@ -1,4 +1,4 @@
-.TH PCRE2PERFORM 3 "08 April 2017" "PCRE2 10.30"
+.TH PCRE2PERFORM 3 "25 April 2018" "PCRE2 10.32"
 .SH NAME
 PCRE2 - Perl-compatible regular expressions (revised API)
 .SH "PCRE2 PERFORMANCE"
@@ -34,9 +34,9 @@ example, the very simple pattern
 .sp
   ((ab){1,1000}c){1,3}
 .sp
-uses over 50K bytes when compiled using the 8-bit library. When PCRE2 is
+uses over 50KiB when compiled using the 8-bit library. When PCRE2 is
 compiled with its default internal pointer size of two bytes, the size limit on
-a compiled pattern is 64K code units in the 8-bit and 16-bit libraries, and
+a compiled pattern is 65535 code units in the 8-bit and 16-bit libraries, and
 this is reached with the above pattern if the outer repetition is increased
 from 3 to 4. PCRE2 can be compiled to use larger internal pointers and thus
 handle larger compiled patterns, but it is better to try to rewrite your
@@ -52,14 +52,14 @@ facility. Re-writing the above pattern as
 .sp
   ((ab)(?2){0,999}c)(?1){0,2}
 .sp
-reduces the memory requirements to around 16K, and indeed it remains under 20K
-even with the outer repetition increased to 100. However, this kind of pattern
-is not always exactly equivalent, because any captures within subroutine calls
-are lost when the subroutine completes. If this is not a problem, this kind of
-rewriting will allow you to process patterns that PCRE2 cannot otherwise
-handle. The matching performance of the two different versions of the pattern
-are roughly the same. (This applies from release 10.30 - things were different
-in earlier releases.)
+reduces the memory requirements to around 16KiB, and indeed it remains under
+20KiB even with the outer repetition increased to 100. However, this kind of
+pattern is not always exactly equivalent, because any captures within
+subroutine calls are lost when the subroutine completes. If this is not a
+problem, this kind of rewriting will allow you to process patterns that PCRE2
+cannot otherwise handle. The matching performance of the two different versions
+of the pattern are roughly the same. (This applies from release 10.30 - things
+were different in earlier releases.)
 .
 .
 .SH "STACK AND HEAP USAGE AT RUN TIME"
@@ -69,7 +69,7 @@ From release 10.30, the interpretive (non-JIT) version of \fBpcre2_match()\fP
 uses very little system stack at run time. In earlier releases recursive
 function calls could use a great deal of stack, and this could cause problems,
 but this usage has been eliminated. Backtracking positions are now explicitly
-remembered in memory frames controlled by the code. An initial 20K vector of
+remembered in memory frames controlled by the code. An initial 20KiB vector of
 frames is allocated on the system stack (enough for about 100 frames for small
 patterns), but if this is insufficient, heap memory is used. The amount of heap
 memory can be limited; if the limit is set to zero, only the initial stack
@@ -78,9 +78,16 @@ may also reduce the memory requirements.
 .P
 In contrast to \fBpcre2_match()\fP, \fBpcre2_dfa_match()\fP does use recursive
 function calls, but only for processing atomic groups, lookaround assertions,
-and recursion within the pattern. Too much nested recursion may cause stack
-issues. The "match depth" parameter can be used to limit the depth of function
-recursion in \fBpcre2_dfa_match()\fP.
+and recursion within the pattern. The original version of the code used to
+allocate quite large internal workspace vectors on the stack, which caused some
+problems for some patterns in environments with small stacks. From release
+10.32 the code for \fBpcre2_dfa_match()\fP has been re-factored to use heap
+memory when necessary for internal workspace when recursing, though recursive
+function calls are still used.
+.P
+The "match depth" parameter can be used to limit the depth of function
+recursion, and the "match heap" parameter to limit heap memory in
+\fBpcre2_dfa_match()\fP.
 .
 .
 .SH "PROCESSING TIME"
@@ -232,6 +239,6 @@ Cambridge, England.
 .rs
 .sp
 .nf
-Last updated: 08 April 2017
-Copyright (c) 1997-2017 University of Cambridge.
+Last updated: 25 April 2018
+Copyright (c) 1997-2018 University of Cambridge.
 .fi