Re:Go’s hidden pragmas
by saagarjha on Monday January 08, 2018 @10:28AM
(#16097350)
Yeah, that’s what I was getting at. Race condition detection would probably slow down your code, so you probably wouldn’t use it in production.
[ Parent
| on HN ]
Race detection is totally disabled for production binaries, because it does slow down the code.
The question is: For debug builds that explicitly have the "-race" flag passed to the compiler, why would you want to disable race detection for a specific function?
I actually do have a real example of this.
We use -race during our automated testing. The setup for some of our tests involves CPU mining (rapid blake2b hashing). This code definitely doesn't have any races, and it runs waaaaay slower when race detection is enabled. So we could speed up our tests significantly by disabling race detection just for the setup phase.
Have you considered enabling parallel tests for that package? It let's test functions run in parallel with each other. Might address some of the issue with the performance.