--- embedaddon/pcre/doc/pcreperform.3	2012/02/21 23:05:51	1.1.1.1
+++ embedaddon/pcre/doc/pcreperform.3	2012/02/21 23:50:25	1.1.1.2
@@ -11,9 +11,9 @@ of them.
 .SH "COMPILED PATTERN MEMORY USAGE"
 .rs
 .sp
-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
@@ -34,12 +34,12 @@ example, the very simple pattern
 .sp
   ((ab){1,1000}c){1,3}
 .sp
-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.
 .P
 One way of reducing the memory usage for such patterns is to make use of PCRE's
 .\" HTML <a href="pcrepattern.html#subpatternsassubroutines">
@@ -68,11 +68,11 @@ that PCRE cannot otherwise handle.
 .SH "STACK USAGE AT RUN TIME"
 .rs
 .sp
-When \fBpcre_exec()\fP 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 \fBpcre_exec()\fP or \fBpcre16_exec()\fP 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
 .\" HREF
 \fBpcrestack\fP
 .\"
@@ -101,8 +101,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 \ed, when matched with
-\fBpcre_exec()\fP; the performance loss is less with \fBpcre_dfa_exec()\fP, and
-in both cases there is not much difference for \eb.
+a traditional matching function; the performance loss is less with
+a DFA matching function, and in both cases there is not much difference for
+\eb.
 .P
 When a pattern begins with .* not in parentheses, or in parentheses that are
 not the subject of a backreference, and the PCRE_DOTALL option is set, the
@@ -172,6 +173,6 @@ Cambridge CB2 3QH, England.
 .rs
 .sp
 .nf
-Last updated: 16 May 2010
-Copyright (c) 1997-2010 University of Cambridge.
+Last updated: 09 January 2012
+Copyright (c) 1997-2012 University of Cambridge.
 .fi