News for hackers. Stuff that matters.
Re:Stop avoiding regular expressions damn it by Titanous on Sunday May 12, 2013 @09:56AM (#5694218)
More 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 by btilly on Sunday May 12, 2013 @10:30AM (#5694363)
That 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.

Re:Stop avoiding regular expressions damn it by kamaal on Sunday May 12, 2013 @10:25AM (#5694346)
Last 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.
Re:Stop avoiding regular expressions damn it by buro9 on Sunday May 12, 2013 @10:14AM (#5694292)
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 by Titanous on Sunday May 12, 2013 @10:17AM (#5694313)
It does have the MustCompile outside of the loop. I pasted the wrong link originally.
Re:Stop avoiding regular expressions damn it by buro9 on Sunday May 12, 2013 @10:20AM (#5694321)
Ah, my apology I saw the earlier link.
Re:Stop avoiding regular expressions damn it by Achshar on Sunday May 12, 2013 @10:23AM (#5694336)
If I am reading the chart correctly, doubled performance would still not be enough.
Re:Stop avoiding regular expressions damn it by buro9 on Sunday May 12, 2013 @10:26AM (#5694351)
Absolutely. 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.

Re:Stop avoiding regular expressions damn it by rcfox on Sunday May 12, 2013 @10:12AM (#5694284)
Just 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.

Re:Stop avoiding regular expressions damn it by Titanous on Sunday May 12, 2013 @10:14AM (#5694295)

    `\A@(.*)@\z`

    BenchmarkRegexp	  500000	      5181 ns/op
    BenchmarkStrings	10000000	       171 ns/op
Re:Stop avoiding regular expressions damn it by ralph on Sunday May 12, 2013 @10:33AM (#5694372)
No, not always. That's a poor example biased to simple string handling.
Re:Stop avoiding regular expressions damn it by coolsunglasses on Sunday May 12, 2013 @12:40PM (#5694836)
Using 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.
Re:Stop avoiding regular expressions damn it by Titanous on Sunday May 12, 2013 @04:12PM (#5695651)
It'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

Re:Stop avoiding regular expressions damn it by kbenson on Monday May 13, 2013 @12:56AM (#5697257)
Not just a different design, a different set of features. For example, no backreferences.
Re:Stop avoiding regular expressions damn it by bradt on Sunday May 12, 2013 @10:00AM (#5694230)
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?
Re:Stop avoiding regular expressions damn it by Titanous on Sunday May 12, 2013 @10:03AM (#5694244)
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.

Re:Stop avoiding regular expressions damn it by bradt on Sunday May 12, 2013 @10:22AM (#5694332)
Agreed.