77 lines
3.4 KiB
Groff
77 lines
3.4 KiB
Groff
.TH PCREPERFORM 3
|
|
.SH NAME
|
|
PCRE - Perl-compatible regular expressions
|
|
.SH "PCRE PERFORMANCE"
|
|
.rs
|
|
.sp
|
|
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 \ep, \eP, and \eX 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
|
|
.sp
|
|
.*second
|
|
.sp
|
|
matches the subject "first\enand second" (where \en 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 ^.* or ^.*? 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
|
|
.sp
|
|
(a+)*
|
|
.sp
|
|
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
|
|
.sp
|
|
(a+)*b
|
|
.sp
|
|
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
|
|
.sp
|
|
(a+)*\ed
|
|
.sp
|
|
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
|
|
.in 0
|
|
Last updated: 28 February 2005
|
|
.br
|
|
Copyright (c) 1997-2005 University of Cambridge.
|