From 0a55fa14f462169bbd8a8de623804f039854f95f Mon Sep 17 00:00:00 2001 From: dartraiden Date: Fri, 1 Jun 2018 18:25:57 +0300 Subject: we only needs license, contributors and version info --- libs/Pcre16/docs/doc/html/pcreperform.html | 195 ----------------------------- 1 file changed, 195 deletions(-) delete mode 100644 libs/Pcre16/docs/doc/html/pcreperform.html (limited to 'libs/Pcre16/docs/doc/html/pcreperform.html') diff --git a/libs/Pcre16/docs/doc/html/pcreperform.html b/libs/Pcre16/docs/doc/html/pcreperform.html deleted file mode 100644 index dda207f901..0000000000 --- a/libs/Pcre16/docs/doc/html/pcreperform.html +++ /dev/null @@ -1,195 +0,0 @@ - - -pcreperform specification - - -

pcreperform man page

-Return to the PCRE index page. -

-This page is part of the PCRE HTML documentation. It was 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. -
-
-PCRE PERFORMANCE -
-

-Two aspects of performance are discussed below: memory usage and processing -time. The way you express your pattern as a regular expression can affect both -of them. -

-
-COMPILED PATTERN MEMORY USAGE -
-

-Patterns are compiled by PCRE into a reasonably efficient interpretive code, so -that most simple patterns do not use much memory. 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 subpattern is repeated in the compiled code. For -example, the pattern -

-  (abc|def){2,4}
-

-is compiled as if it were -

-  (abc|def)(abc|def)((abc|def)(abc|def)?)?
-

-(Technical aside: It is done this way so that backtrack points within each of -the repetitions can be independently maintained.) -

-For regular expressions whose quantifiers use only small numbers, this is not -usually a problem. However, if the numbers are large, and particularly if such -repetitions are nested, the memory usage can become an embarrassment. For -example, the very simple pattern -

-  ((ab){1,1000}c){1,3}
-

-uses 51K bytes when compiled using the 8-bit library. When PCRE is compiled -with its default internal pointer size of two bytes, the size limit on a -compiled pattern is 64K data units, and this is reached with the above pattern -if the outer repetition is increased from 3 to 4. PCRE can be compiled to use -larger internal pointers and thus handle larger compiled patterns, but it is -better to try to rewrite your pattern to use less memory if you can. -

-One way of reducing the memory usage for such patterns is to make use of PCRE's -"subroutine" -facility. Re-writing the above pattern as -

-  ((ab)(?2){0,999}c)(?1){0,2}
-

-reduces the memory requirements to 18K, and indeed it remains under 20K even -with the outer repetition increased to 100. However, this pattern is not -exactly equivalent, because the "subroutine" calls are treated as -atomic groups -into which there can be no backtracking if there is a subsequent matching -failure. Therefore, PCRE cannot do this kind of rewriting automatically. -Furthermore, there is a noticeable loss of speed when executing the modified -pattern. Nevertheless, if the atomic grouping is not a problem and the loss of -speed is acceptable, this kind of rewriting will allow you to process patterns -that PCRE cannot otherwise handle. -

-
-STACK USAGE AT RUN TIME -
-

-When pcre_exec() or pcre[16|32]_exec() is used for matching, certain -kinds of pattern can cause it to use large amounts of the process stack. In -some environments the default process stack is quite small, and if it runs out -the result is often SIGSEGV. This issue is probably the most frequently raised -problem with PCRE. Rewriting your pattern can often help. The -pcrestack -documentation discusses this issue in detail. -

-
-PROCESSING TIME -
-

-Certain items in regular expression patterns are processed more efficiently -than others. It is more efficient to use a character class like [aeiou] than a -set of single-character 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. -

-Using Unicode character properties (the \p, \P, and \X escapes) is slow, -because PCRE has to use a multi-stage table lookup 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. -

-By default, the escape sequences \b, \d, \s, and \w, and the POSIX -character classes such as [:alpha:] do not use Unicode properties, partly for -backwards compatibility, and partly for performance reasons. However, you can -set PCRE_UCP if you want Unicode character properties to be used. This can -double the matching time for items such as \d, when matched with -a traditional matching function; the performance loss is less with -a DFA matching function, and in both cases there is not much difference for -\b. -

-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 -

-  .*second
-

-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. -

-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. -

-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 -

-  ^(a+)*
-

-This can match "aaaa" in 16 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 or 4, 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, even for relatively short -strings. -

-An optimization catches some of the more simple cases such as -

-  (a+)*b
-

-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 -

-  (a+)*\d
-

-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. -

-In many cases, the solution to this kind of performance issue is to use an -atomic group or a possessive quantifier. -

-
-AUTHOR -
-

-Philip Hazel -
-University Computing Service -
-Cambridge CB2 3QH, England. -
-

-
-REVISION -
-

-Return to the PCRE index page. -

-- cgit v1.2.3