[Mono-dev] 6198, Opinion? (not a fix)

[Rob Wilkens]

1) My original fix for 2663 i knew would be slower than the original
without it because it had to do more to handle all possibilties for ors
introduced with bug 2663's report.  For those unfamiliar -- (A|AB|ABC)
if you tried to match that against ABC it would first match with "A"
(which is valid) and move on without matching "AB" or "ABC" which are
both also valid, so now we have to try all possibilities -- and all
combinations of possibilities of matches.).

2) The report in 6198 found a way where there were 70 or conditions
matched which had to be tried in all various combinations to see if this
would work.  This ran slow, very slow.  Unfortuantely, the old fast way
just didn't work right at all, so slow and correct is probably better
than fast and incorrect.  Still, there should be a better way.

3) The report in 6198 appears to have code which fails to find matches
both with and without this 2663 patch, i don't remember now - it was on
another os install that i did the testing and don't have the code in
front of me.  That may be another problem, but unrelated to my patch.

4) I realize a quick fix to make this work fast would be to look at the
source to other open source reg ex parsers and see how they do it, but i
don't know how compatible that would be with the license that we are
using with Mono (MIT/X11?).  i.e. taking gpl'd code and inserting it
here might be unacceptable - which is why i did it without looking at
other working code.

5) If someone else wants to take a shot at this, feel free.  I made it
work right with 2663, but if it's slow do we want right?  Is speed
better than correctness?

I can probably come up with a better fix.  I think the list of
JumpTestLists's we've tried could probably be sorted by something better
than it is now by using something like a tree search (different storage
and compare) rather than just a list of lists to manually check against
(possibly with duplicates), that might give some speed improvements. 
I'm not sure right now if i have the patience to do this at least not at
8:30am.  it's probably worth a shot, though.

I won't give up on this yet, i'd like to think i can make it faster than
it is, please just keep 6198 open until i get a chance.  And don't apply
any of the fixes i submitted on the mailing list, they're probably
incorrect and were rushed without thinking through -- the original 2663
fix was more thought out, though more focused on functionality than
optimization.