1 |
.TH PCRE 3
|
2 |
.SH NAME
|
3 |
PCRE - Perl-compatible regular expressions
|
4 |
.SH PCRE PERFORMANCE
|
5 |
.rs
|
6 |
.sp
|
7 |
Certain items that may appear in regular expression patterns are more efficient
|
8 |
than others. It is more efficient to use a character class like [aeiou] than a
|
9 |
set of alternatives such as (a|e|i|o|u). In general, the simplest construction
|
10 |
that provides the required behaviour is usually the most efficient. Jeffrey
|
11 |
Friedl's book contains a lot of discussion about optimizing regular expressions
|
12 |
for efficient performance.
|
13 |
|
14 |
When a pattern begins with .* not in parentheses, or in parentheses that are
|
15 |
not the subject of a backreference, and the PCRE_DOTALL option is set, the
|
16 |
pattern is implicitly anchored by PCRE, since it can match only at the start of
|
17 |
a subject string. However, if PCRE_DOTALL is not set, PCRE cannot make this
|
18 |
optimization, because the . metacharacter does not then match a newline, and if
|
19 |
the subject string contains newlines, the pattern may match from the character
|
20 |
immediately following one of them instead of from the very start. For example,
|
21 |
the pattern
|
22 |
|
23 |
.*second
|
24 |
|
25 |
matches the subject "first\\nand second" (where \\n stands for a newline
|
26 |
character), with the match starting at the seventh character. In order to do
|
27 |
this, PCRE has to retry the match starting after every newline in the subject.
|
28 |
|
29 |
If you are using such a pattern with subject strings that do not contain
|
30 |
newlines, the best performance is obtained by setting PCRE_DOTALL, or starting
|
31 |
the pattern with ^.* to indicate explicit anchoring. That saves PCRE from
|
32 |
having to scan along the subject looking for a newline to restart at.
|
33 |
|
34 |
Beware of patterns that contain nested indefinite repeats. These can take a
|
35 |
long time to run when applied to a string that does not match. Consider the
|
36 |
pattern fragment
|
37 |
|
38 |
(a+)*
|
39 |
|
40 |
This can match "aaaa" in 33 different ways, and this number increases very
|
41 |
rapidly as the string gets longer. (The * repeat can match 0, 1, 2, 3, or 4
|
42 |
times, and for each of those cases other than 0, the + repeats can match
|
43 |
different numbers of times.) When the remainder of the pattern is such that the
|
44 |
entire match is going to fail, PCRE has in principle to try every possible
|
45 |
variation, and this can take an extremely long time.
|
46 |
|
47 |
An optimization catches some of the more simple cases such as
|
48 |
|
49 |
(a+)*b
|
50 |
|
51 |
where a literal character follows. Before embarking on the standard matching
|
52 |
procedure, PCRE checks that there is a "b" later in the subject string, and if
|
53 |
there is not, it fails the match immediately. However, when there is no
|
54 |
following literal this optimization cannot be used. You can see the difference
|
55 |
by comparing the behaviour of
|
56 |
|
57 |
(a+)*\\d
|
58 |
|
59 |
with the pattern above. The former gives a failure almost instantly when
|
60 |
applied to a whole line of "a" characters, whereas the latter takes an
|
61 |
appreciable time with strings longer than about 20 characters.
|
62 |
|
63 |
.in 0
|
64 |
Last updated: 03 February 2003
|
65 |
.br
|
66 |
Copyright (c) 1997-2003 University of Cambridge.
|