regcomp.c: Reinstate use of synthetic start class
authorKarl Williamson <public@khwilliamson.com>
Sun, 29 Dec 2013 04:48:57 +0000 (21:48 -0700)
committerKarl Williamson <public@khwilliamson.com>
Tue, 31 Dec 2013 15:01:03 +0000 (08:01 -0700)
commit749e076fceedeb708a624933726e7989f2302f6a
tree3be9711bd70eeb2bc1c0c706d59941c7fe1f0af1
parent5aa91856e21c93226d08f19eb69098f224de5fff
regcomp.c: Reinstate use of synthetic start class

This effectively reverts commit
a74bca75951b6a3b0ad03ba07eb31e2ca1227308, although the syntax has
changed.  This commit inadvertently caused a synthetic start class (SSC)
to not be generated in many cases where it previously was.  The
SSC is generated by the regex optimizer to hopefully speed up finding
where to start matching the target string against the regex pattern.  I
don't know if this is a valid data point, but in the 3 months that this
was in blead, there were no complaints of a slowdown that could be
attributed to this.

The commit that caused this was made after discussing it with Yves
Orton.  It just seemed (and still seems) wrong that doing what the code
indicates is a logical OR should actually restrict the possibilities.
The change essentially caused the result of OR'ing together the matches
of two nodes, one of which nominally could match a sub-string of zero
length, to also match a sub-string of zero length.  Previous to that
commit, and after this new one, the result of doing the OR excludes a
zero-length string, as if it were an AND.

The end result of the change was that the SSC could match a zero-length
string, and thus was discarded as not being useful.  Yves and I knew
that the change would not cause bugs; just potentially create more false
positives.  And we were right.

I believe that this is further indication that the optimizer could
benefit greatly from an overhaul.  It's clear from looking at the code
and commits that other people have been similarly fooled.
regcomp.c
t/re/pat.t