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

[Stifu]

Although you ask, you probably already know the answer: correctness is
preferable to speed. Sure, if we can have both, that'd be great, but if we
had to choose, let's be correct.


Rob Wilkens wrote
> 
> 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.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at .ximian
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 




--
View this message in context: http://mono.1490590.n4.nabble.com/6198-Opinion-not-a-fix-tp4650679p4650682.html
Sent from the Mono - Dev mailing list archive at Nabble.com.