Code tidies for 10.30-RC1 release candidate.

git-svn-id: svn://vcs.exim.org/pcre2/code/trunk@842 6239d852-aaf2-0410-a92c-79f79f948069

1 files changed, 6 insertions, 6 deletions

diff --git a/doc/html/pcre2perform.html b/doc/html/pcre2perform.html
index 1a53493..28f4f73 100644
--- a/doc/html/pcre2perform.html
+++ b/doc/html/pcre2perform.html
@@ -29,7 +29,7 @@ of them.
 <br><a name="SEC2" href="#TOC1">COMPILED PATTERN MEMORY USAGE</a><br>
 <P>
 Patterns are compiled by PCRE2 into a reasonably efficient interpretive code,
-so that most simple patterns do not use much memory for storing the compiled 
+so that most simple patterns do not use much memory for storing the compiled
 version. 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
@@ -91,7 +91,7 @@ vector is used. Rewriting patterns to be time-efficient, as described below,
 may also reduce the memory requirements.
 </P>
 <P>
-In contrast to <b>pcre2_match()</b>, <b>pcre2_dfa_match()</b> does use recursive 
+In contrast to <b>pcre2_match()</b>, <b>pcre2_dfa_match()</b> 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
@@ -184,7 +184,7 @@ appreciable time with strings longer than about 20 characters.
 </P>
 <P>
 In many cases, the solution to this kind of performance issue is to use an
-atomic group or a possessive quantifier. This can often reduce memory 
+atomic group or a possessive quantifier. This can often reduce memory
 requirements as well. As another example, consider this pattern:
 <pre>
   ([^&#60;]|&#60;(?!inet))+
@@ -205,7 +205,7 @@ are "swallowed" in one item inside the parentheses, and a possessive quantifier
 is used to stop any backtracking into the runs of non-"&#60;" characters. This
 version also uses a lot less memory because entry to a new set of parentheses
 happens only when a "&#60;" character that is not followed by "inet" is encountered
-(and we assume this is relatively rare). 
+(and we assume this is relatively rare).
 </P>
 <P>
 This example shows that one way of optimizing performance when matching long
@@ -216,10 +216,10 @@ than one character whenever possible.
 SETTING RESOURCE LIMITS
 </b><br>
 <P>
-You can set limits on the amount of processing that takes place when matching, 
+You can set limits on the amount of processing that takes place when matching,
 and on the amount of heap memory that is used. The default values of the limits
 are very large, and unlikely ever to operate. They can be changed when PCRE2 is
-built, and they can also be set when <b>pcre2_match()</b> or 
+built, and they can also be set when <b>pcre2_match()</b> or
 <b>pcre2_dfa_match()</b> is called. For details of these interfaces, see the
 <a href="pcre2build.html"><b>pcre2build</b></a>
 documentation and the section entitled