1) Can you give a list of conditions and methods on when and how the regex optimization applies?
eg: regex:"a\\|b\\", will it be optimized to <a\|b\>?
No optimization is used if the regex expression contains any special regex characters:
[ ]
.
*
{ }
?
+
|
( )
^
$
(it's a little more complicated as Everything does process escaped characters with \, for example: \Q..\E or \.)
2) How much imporved performance will be achieved by such an optimization?
Timing and OP code information is reported in the
debug console.
Check the performance between:
regex:"dl\\"
no-fast-regex:regex:"dl\\"
3) "()" are special characters, so as long as the regex has one group, it won't be optimized, right?
Correct.
". * + ? []", do these chars also considered special?
Yes.
4) Can we know the priority list of search terms used to re-order?
Tough to do as each search function has many OP codes and each OP code is weighted.
Search reordering is only applied to ANDed op codes where the order doesn't matter.
5) I won't favor such changes if the performance will drop significantly.
Capturing the correct information will always be more important than performance.
Any performance loss will be negligible compared to a search op that recalls a regmatch. (eg: fileexists:)
6) For now, when will fast-regex/re-order be disabled implicitly?
When you reference a regmatch0-9 with fileexists:/folderexists: (in the next alpha update)
When using the expand: search modifier.
When using child: and child-occurrence-count:
when using column assignment, for example: col1:=LEN($regmatch1:)
when comparing regmatches, for example: regmatch1:==regmatch2:
when using noreorder: search modifier.
when using regmatch0-9: search function.
when using a sibling: with $1-9:
when using eval: search function, for example: eval:LEN($regmatch1:)>LEN($regmatch2:)
. slow_op() && fast_op() can be re-ordered to fast_op() && slow_op(), which speed-up the search and not affect the final result.