Earlier quoted context omitted.
Thanks for clarifying. I guess my point was that if you're just matching one email address in a form submission for example, is performance significant?
No, a few µs vs a few ns when processing your web form won't be significant. Don't shy away from regular expressions, but be aware of their performance and readability impact. The problem is when developers that don't know any better build parsers with regular expressions. That's almost always a bad idea.
Stop avoiding regular expressions damn it
31–40 of 55 posts
Re: Stop avoiding regular expressions damn it
#32More concise? Sometimes. Slower? Always. BenchmarkRegexp 500000 5136 ns/op BenchmarkStrings 10000000 173 ns/op http://play.golang.org/p/YT29Ao-tOt
You could more than double the performance of the regexp if you did MustCompile just the once rather than within every loop. MustCompile is generally used to make the regexp a global so that it isn't done over and over. Just move it out of the loop, as it's really not necessary to compile regular expressions every time you want to match/replace against it.
Re: Stop avoiding regular expressions damn it
#33More concise? Sometimes. Slower? Always. BenchmarkRegexp 500000 5136 ns/op BenchmarkStrings 10000000 173 ns/op http://play.golang.org/p/YT29Ao-tOt
Re: Stop avoiding regular expressions damn it
#34Stop propagating bad interfaces like 'regular expressions' damn it! An interface that e.g. makes me 'escape' half of my input because its designers think their special use of characters must take precedence over all user input is a bad interface.
In Perl, it's called quotemeta (qw, qq and family, too), in Python and Ruby it's .escape... and there's always \Q ... \E to use...
I'm sure others have similar methods/functions.
Re: Stop avoiding regular expressions damn it
#35Stop propagating bad interfaces like 'regular expressions' damn it! An interface that e.g. makes me 'escape' half of my input because its designers think their special use of characters must take precedence over all user input is a bad interface.
That always makes me giggle.
Re: Stop avoiding regular expressions damn it
#36Earlier quoted context omitted.
You could more than double the performance of the regexp if you did MustCompile just the once rather than within every loop. MustCompile is generally used to make the regexp a global so that it isn't done over and over. Just move it out of the loop, as it's really not necessary to compile regular expressions every time you want to match/replace against it.
If I am reading the chart correctly, doubled performance would still not be enough.
For trivial replacements string manipulation I find is faster and safer (fewer bugs). But there is some threshold of complexity in which regular expressions are both more performant and safer.
Re: Stop avoiding regular expressions damn it
#37The core criticism of regular expressions is legitimately directed at intermediate programmers who know enough to be dangerous, but is sometimes inappropriately cargo-culted by beginner programmers who use it as an excuse not to learn regular expressions. The fact is that despite pithy slogans, there is a sweet spot where a regular expression does the job of matching a string in a clearer fashion than anything else.…
Re: Stop avoiding regular expressions damn it
#38Stop propagating bad interfaces like 'regular expressions' damn it! An interface that e.g. makes me 'escape' half of my input because its designers think their special use of characters must take precedence over all user input is a bad interface.
Re: Stop avoiding regular expressions damn it
#39More concise? Sometimes. Slower? Always. BenchmarkRegexp 500000 5136 ns/op BenchmarkStrings 10000000 173 ns/op http://play.golang.org/p/YT29Ao-tOt
The classic example is to recognize that you're looking for a fixed string, and substitute in Boyer Moore. But prefix/suffix recognition are two other common examples.
Re: Stop avoiding regular expressions damn it
#40More concise? Sometimes. Slower? Always. BenchmarkRegexp 500000 5136 ns/op BenchmarkStrings 10000000 173 ns/op http://play.golang.org/p/YT29Ao-tOt