On Sun, Feb 12, 2012 at 3:43 AM, Aaron Patterson <[email protected]>wrote:
Ya, but if we're going to put arbitrary restrictions on the type of > matches people can do (i.e. no backreferences), you may as well use an > engine that can execute in O(n) time (n = string length). Otherwise, > what's the point? > I don't claim this approach is better in complexity theoretically. It isn't. The point is that for what I think are typical scenarios the regexp engine loops and matches so much faster than in practice this is a potential important speedup. Also I am aiming at max backwards compat. Disallowing backreferences is not going to be a big deal I think because I doubt they are used much in inflection rules (though I asked to the ML in case there's some use case that says we have to support them). Of course if we restrict the regexp features to a very small set we can write a scanner ourselves. But you'd still be doing basically what the regexp engine does, and without the optimizations oniguruma may have implemented after analyzing the regexp. Because you need to go in order and per each fragment either match the whole pattern or fail fast and try the next fragment right? That's already what happens with alternation no? Can you beat that and still support regexps without backreferences? How did you determine the length of the strings that most people use? I > think seeing this data would be useful in speeding up this code. > I am guessing of course, based on my experience. Also, you do not pluralize sentences or text files no? You pluralize words, that's the expected input statistically speaking and the one that has to guide us in implementing this I believe. Nowadays long strings get a performance boost. That does not make sense statistically speaking, English words should be the fast ones. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
