Add regexp benchmark test #387
Conversation
| for i := 0; i < numGoroutines; i++ { | ||
| go func() { | ||
| re.MatchString(line) | ||
| c <- 1 |
There was a problem hiding this comment.
Mentioned when we discussed yesterday - channels are fairly expensive. What I didn't think to mention is you can use a waitgroup to do the same for cheaper - which would reduce the amount of possible skewing factors in the benchmark.
Not asking you to change it here - just following up with relevant info that I neglected to mention yesterday. I think what you have here measures things equally enough for our purposes.
| } | ||
|
|
||
|
|
||
| // Results |
There was a problem hiding this comment.
OK interesting - these results indicate that there's negligible difference between the approaches. Which would mean that the implementation doesn't introduce an unnecessary bottleneck on filtering. Good to know!
I'll re-run on my machine to confirm too.
| ) | ||
|
|
||
| func Benchmark_OriginalPattern_Simple_Match(b *testing.B) { | ||
| regexToMatch, err := regexp.Compile(simpleRegexp) |
There was a problem hiding this comment.
This is simpler than the switch function!
If you did want to generalise the repeated code here further, it could be achieved by passing b as a parameter. In this case I don't think it'd be necessary/worth the effort just to factor the code, but for future reference that's an option!
We use that pattern in snowman tests a lot - and it is worth the effort there, because we often want to do the same test-related things across many different tests. (Although that code base is quite complex - not something I'd point to as being a perfect example of simplification!)
Making PR so I can leave comments - didn't think of the fact that I couldn't otherwise