diff options
Diffstat (limited to 'external-libs/pcre/doc/html/pcreperform.html')
-rw-r--r-- | external-libs/pcre/doc/html/pcreperform.html | 93 |
1 files changed, 93 insertions, 0 deletions
diff --git a/external-libs/pcre/doc/html/pcreperform.html b/external-libs/pcre/doc/html/pcreperform.html new file mode 100644 index 00000000..418ac6d4 --- /dev/null +++ b/external-libs/pcre/doc/html/pcreperform.html @@ -0,0 +1,93 @@ +<html> +<head> +<title>pcreperform specification</title> +</head> +<body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB"> +This HTML document has been generated automatically from the original man page. +If there is any nonsense in it, please consult the man page, in case the +conversion went wrong.<br> +<ul> +<li><a name="TOC1" href="#SEC1">PCRE PERFORMANCE</a> +</ul> +<br><a name="SEC1" href="#TOC1">PCRE PERFORMANCE</a><br> +<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 discussion about optimizing regular expressions +for efficient performance. +</P> +<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> +<P> +<pre> + .*second +</PRE> +</P> +<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> +<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> +<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> +<P> +<pre> + (a+)* +</PRE> +</P> +<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> +<P> +An optimization catches some of the more simple cases such as +</P> +<P> +<pre> + (a+)*b +</PRE> +</P> +<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> +<P> +<pre> + (a+)*\d +</PRE> +</P> +<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> +<P> +Last updated: 03 February 2003 +<br> +Copyright © 1997-2003 University of Cambridge. |