Re: [pcre-dev] Influence of some start-up optimizations at the beginning of the pattern
On 2019-05-29 16:52, ph10 wrote: On Wed, 29 May 2019, ND via Pcre-dev wrote: Since anybody put MARK verb at the beginning of pattern then it is assumed > that this verb is definitely needed in pattern logic. But maybe only for successful matches? So is there any reason to apply to such patterns optimizations that can > discard that MARK? > May be automatically disabling of such optimizations is reasonable. The discarding happens only for "no match" results. If you areinterested only in matches, the optimizations are fine. My fault. Completely agree with you. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Influence of some start-up optimizations at the beginning of the pattern
On Wed, 29 May 2019, ND via Pcre-dev wrote: > Since anybody put MARK verb at the beginning of pattern then it is assumed > that this verb is definitely needed in pattern logic. But maybe only for successful matches? > So is there any reason to apply to such patterns optimizations that can > discard that MARK? > May be automatically disabling of such optimizations is reasonable. The discarding happens only for "no match" results. If you are interested only in matches, the optimizations are fine. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Influence of some start-up optimizations at the beginning of the pattern
Since anybody put MARK verb at the beginning of pattern then it is assumed that this verb is definitely needed in pattern logic. So is there any reason to apply to such patterns optimizations that can discard that MARK? May be automatically disabling of such optimizations is reasonable. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Influence of some start-up optimizations at the beginning of the pattern
On Wed, 29 May 2019, ND via Pcre-dev wrote: > But it seems no difference in pcre2test output in normal and no_start_optimize > cases. Both returned mark value: > > > PCRE2 version 10.33 2019-04-16 > /(*MARK:A)(X|Y)/mark > ABC > No match, mark = A > > /(*MARK:A)(X|Y)/mark,no_start_optimize > ABC > No match, mark = A Thank you for pointing this out. It is a mistake in the documentation. The reason is that, for a "no match", the MARK returned is the last one seen during the whole match process, not just in the last starting position. Here is a better example: $ ./pcre2test zz PCRE2 version 10.33 2019-04-16 /(*MARK:A)B(*MARK:B)(X|Y)/mark XXXBZ No match, mark = B /(*MARK:A)B(*MARK:B)(X|Y)/mark,no_start_optimize XXXBZ No match, mark = A I will update the documentation in due course. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] Influence of some start-up optimizations at the beginning of the pattern
Good day! pcre2api.html document: There are also other start-up optimizations. For example, a minimum length for the subject may be recorded. Consider the pattern (*MARK:A)(X|Y) The minimum length for a match is one character. If the subject is "ABC", there will be attempts to match "ABC", "BC", and "C". An attempt to match an empty string at the end of the subject does not take place, because PCRE2 knows that the subject is now too short, and so the (*MARK) is never encountered. In this case, the optimization does not affect the overall match result, which is still "no match", but it does affect the auxiliary information that is returned. But it seems no difference in pcre2test output in normal and no_start_optimize cases. Both returned mark value: PCRE2 version 10.33 2019-04-16 /(*MARK:A)(X|Y)/mark ABC No match, mark = A /(*MARK:A)(X|Y)/mark,no_start_optimize ABC No match, mark = A Tell please about what information are words "it does affect the auxiliary information that is returned "? May be some correction to docs needed? Thanks -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
