Filtered-out log.Level lines still cost #15
-
I noticed a portion of our CPU was going into I think what is happening is the I looked around but didn't find any previous debate on this point. Am I holding it wrong? Is this expected? Since we are using a wrapper, something like go-kit/kit#322 would let us work around the problem by checking before doing the work, but that was rejected. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
@bboreham I wouldn't say you are holding it wrong, but there may be one tweak to improve it. More on that later. First, let me say up front, that the
If you just want better performance, and you don't need optimal performance, then there is one thing you can do, though. You noted that Playground link for the below code: https://play.golang.org/p/Z3nf1G9jvR0
Note that you cannot use |
Beta Was this translation helpful? Give feedback.
-
Thank you, swapping the filter to last does indeed take out the bulk of the overhead. Would it be better to put the filter last in the example? Lines 6 to 8 in 71fa7d7
I found that, because the go-kit |
Beta Was this translation helpful? Give feedback.
@bboreham I wouldn't say you are holding it wrong, but there may be one tweak to improve it. More on that later.
First, let me say up front, that the
level
package is not designed for raw performance, the behavior you describe is expected. But thelevel
package is also separate from thelog
package precisely because we believed that there was no best way to approach it that would suit everyone's needs. My statement in go-kit/kit#322 (comment) still stands: