3 ms·
More concise? Sometimes. Slower? Always. BenchmarkRegexp 500000 5136 ns/op BenchmarkStrings 10000000 173 ns/op http://play.golang.org/p
by Titanous 13y ago
More concise? Sometimes. Slower? Always.
BenchmarkRegexp 500000 5136 ns/op
BenchmarkStrings 10000000 173 ns/op
http://play.golang.org/p/YT29Ao-tOt http://play.golang.org/p/YT29Ao-tOt
- bradt 13y agoThanks 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?
- Titanous 13y agoNo, 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.
- bradt 13y agoAgreed.
- rcfox 13y agoJust curious: how do the regexes compare when you use "^@(.*)@$" ? Semantically, it's closer to the string version. Realistically, you'd expect them to behave exactly the same, but Go's pretty new, and you never know what is or isn't going to be optimized.
- Titanous 13y ago`\A@(.*)@\z` BenchmarkRegexp 500000 5181 ns/op BenchmarkStrings 10000000 171 ns/op
- buro9 13y agoYou 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.
- deleted 13y ago[deleted]
- Titanous 13y agoIt does have the MustCompile outside of the loop. I pasted the wrong link originally.
- buro9 13y agoAh, my apology I saw the earlier link.
- Achshar 13y agoIf I am reading the chart correctly, doubled performance would still not be enough.
- buro9 13y agoAbsolutely. But the original version linked was twice as slow as need be. 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.
- kamaal 13y agoLast time I checked, any time I needed the power and flexibility of a using a regular expression. Getting the job done was far more and over a degree of magnitude more important than saving some milliseconds of processing time.
- btilly 13y agoThat is an implementation specific benchmark. A grungy real-world regexp engine (such as Perl's) usually will recognize important special cases and substitute in faster code for them. 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.
- ralph 13y agoNo, not always. That's a poor example biased to simple string handling.
- deleted 13y ago[deleted]
- coolsunglasses 13y agoUsing Golang as an example of real world regex performance is borderline dishonest. Their regex engine is notoriously unoptimized and is not intended to be a strong point of the language.
- Titanous 13y agoIt's not "unoptimized", it has a different design[1] than other language implementations, resulting in different performance characteristics. [1] http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html
- kbenson 13y agoNot just a different design, a different set of features. For example, no backreferences.