diff options
Diffstat (limited to 'Utilities/PCRE/man/html/pcreperform.3.html')
| -rw-r--r-- | Utilities/PCRE/man/html/pcreperform.3.html | 86 |
1 files changed, 86 insertions, 0 deletions
diff --git a/Utilities/PCRE/man/html/pcreperform.3.html b/Utilities/PCRE/man/html/pcreperform.3.html new file mode 100644 index 0000000..a4fea50 --- /dev/null +++ b/Utilities/PCRE/man/html/pcreperform.3.html @@ -0,0 +1,86 @@ +<!-- manual page source format generated by PolyglotMan v3.2, -->
+<!-- available at http://polyglotman.sourceforge.net/ -->
+
+<html>
+<head>
+<title>PCRE(3) manual page</title>
+</head>
+<body bgcolor='white'>
+<a href='#toc'>Table of Contents</a><p>
+
+<h2><a name='sect0' href='#toc0'>Name</a></h2>
+PCRE - Perl-compatible regular expressions
+<h2><a name='sect1' href='#toc1'>Pcre Performance</a></h2>
+ <p>
+Certain items
+that may appear in regular expression patterns are more efficient than
+others. It is more efficient to use a character class like [aeiou] than
+a set of alternatives such as (a|e|i|o|u). In general, the simplest construction
+that provides the required behaviour is usually the most efficient. Jeffrey
+Friedl’s book contains a lot of useful general discussion about optimizing
+regular expressions for efficient performance. This document contains a
+few observations about PCRE. <p>
+Using Unicode character properties (the \p,
+\P, and \X escapes) is slow, because PCRE has to scan a structure that contains
+data for over fifteen thousand characters whenever it needs a character’s
+property. If you can find an alternative pattern that does not use character
+properties, it will probably be faster. <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 pattern is implicitly anchored by
+PCRE, since it can match only at the start of a subject string. However,
+if PCRE_DOTALL is not set, PCRE cannot make this optimization, because
+the . metacharacter does not then match a newline, and if the subject string
+contains newlines, the pattern may match from the character immediately
+following one of them instead of from the very start. For example, the pattern
+<p>
+ .*second<br>
+ <p>
+matches the subject "first\nand second" (where \n stands for a newline character),
+with the match starting at the seventh character. In order to do this, PCRE
+has to retry the match starting after every newline in the subject. <p>
+If you
+are using such a pattern with subject strings that do not contain newlines,
+the best performance is obtained by setting PCRE_DOTALL, or starting the
+pattern with ^.* to indicate explicit anchoring. That saves PCRE from having
+to scan along the subject looking for a newline to restart at. <p>
+Beware of
+patterns that contain nested indefinite repeats. These can take a long time
+to run when applied to a string that does not match. Consider the pattern
+fragment <p>
+ (a+)*<br>
+ <p>
+This can match "aaaa" in 33 different ways, and this number increases
+very rapidly as the string gets longer. (The * repeat can match 0, 1, 2,
+3, or 4 times, and for each of those cases other than 0, the + repeats
+can match different numbers of times.) When the remainder of the pattern
+is such that the entire match is going to fail, PCRE has in principle to
+try every possible variation, and this can take an extremely long time.
+<p>
+An optimization catches some of the more simple cases such as <p>
+ (a+)*b<br>
+ <p>
+where a literal character follows. Before embarking on the standard matching
+procedure, PCRE checks that there is a "b" later in the subject string,
+and if there is not, it fails the match immediately. However, when there
+is no following literal this optimization cannot be used. You can see the
+difference by comparing the behaviour of <p>
+ (a+)*\d<br>
+ <p>
+with the pattern above. The former gives a failure almost instantly when
+applied to a whole line of "a" characters, whereas the latter takes an
+appreciable time with strings longer than about 20 characters. <p>
+In many cases,
+the solution to this kind of performance issue is to use an atomic group
+or a possessive quantifier. <p>
+ Last updated: 09 September 2004 <br>
+Copyright (c) 1997-2004 University of Cambridge. <p>
+
+<hr><p>
+<a name='toc'><b>Table of Contents</b></a><p>
+<ul>
+<li><a name='toc0' href='#sect0'>Name</a></li>
+<li><a name='toc1' href='#sect1'>Pcre Performance</a></li>
+</ul>
+</body>
+</html>
|