4 ms·
This seems like a hard-to-expect edge case for real. I think catching edge case is needed (means more rigorous testing). This is the equivalence of algorithm co
by yeukhon 10y ago
This seems like a hard-to-expect edge case for real. I think catching edge case is needed (means more rigorous testing). This is the equivalence of algorithm complexity analysis. How bad can my algorithm be? But regular expression, to be honest, is usually something I hardly think about performance. I don't know about others, but most of the my input are small enough. How big of an input should I test? If I were to deal with a lot of characters, I would be doing substring replacement.
- jrbancel 10y ago> But regular expression, to be honest, is usually something I hardly think about performance. This is actually not an uncommon problem. I recently experienced a backend system going down because of catastrophic backtracking. There is a reason why proper regex libraries have a timeout on the match methods. For example: https://msdn.microsoft.com/en-us/library/hh160204(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/hh160204(v=vs.110)....
- revelation 10y agoA time limit on something like this is so extremely awkward to use. My first problem would be that I'm concerned the implementation doesn't have the resolution; a "reasonable" time limit would be what, 1us for a regex match? Which brings us to the second point: what's this, wall clock time, CPU time? I risk testing this with low load on my dev computer only to have it fail in production because high CPU load means the match just took longer (but wasn't running into a corner case). I think a reasonable "timeout" would be to give an upper limit for character array accesses, like 20*strlen.