4 ms·
It won't, because of inlining and dead code removal. (At least, it didn't back around Go 1.11 when I last tested this.)
by crawshaw 7y ago
It won't, because of inlining and dead code removal. (At least, it didn't back around Go 1.11 when I last tested this.)
- kasey_junk 7y agoMaybe if the thing that is generating the cond at the call location is inline-able, but not if it's doing an expensive operation. https://play.golang.org/p/Ts6QqRrWwuQ https://play.golang.org/p/Ts6QqRrWwuQ I couldn't get that to not trigger the lock. [later] I could get it to remove it if you pass in a func instead.
- chronial 7y agoYour Cond() has a side-effect. It can never be optimized away.
- kasey_junk 7y agoCorrect. Which is one of the differences between this approach & macros. Though the lazy approach appears to work.
- chronial 7y agoIf you do Assert(ExpensiveOp()), removing all of it is only a valid optimization if ExpensiveOp() is 100% side-effect free. But even when that is the case, the compiler won't inline ExpensiveOp() and go through the effort of proving that it's side effect free if it's sufficiently complex.