logger: Check level before creating entry #771
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Calling `time.Now()` and creating an entry is unnecessary if the underlying core has the specified level disabled. To reduce the cost of logs at disabled levels, skip entry creation if the log level is disabled in the core. This special logic does not apply to DPanic or higher logs as they may need to panic/exit even if the entry does not cause any log to be emitted. On my machine, disabled debugging logs are 6x (~60ns to ~10ns). Fixes #770.
Codecov Report
@@ Coverage Diff @@
## master #771 +/- ##
==========================================
+ Coverage 98.19% 98.19% +<.01%
==========================================
Files 42 42
Lines 2269 2271 +2
==========================================
+ Hits 2228 2230 +2
Misses 33 33
Partials 8 8
Continue to review full report at Codecov.
|
|
new test? |
Since this is an optimization, it doesn't have any impact to the functional tests, just a performance improvement. While it is possible to write a test to check for this (we can verify at the core which methods are called), it seems like we're breaking the abstraction. |
|
Perhaps not a test, but perhaps we should add a benchmark for messages being discarded if we don't already have one. |
|
We do have existing benchmarks for this, Will update the summary as well. |
sykesm
added a commit
to sykesm/fabric
that referenced
this pull request
Mar 16, 2020
This picks up uber-go/zap#771. Change-Id: Ic55f3fd29b0d600a3b1c87bd117f7e0a2e0fce04 Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com>
sykesm
added a commit
to hyperledger/fabric
that referenced
this pull request
Mar 16, 2020
This picks up uber-go/zap#771. Change-Id: Ic55f3fd29b0d600a3b1c87bd117f7e0a2e0fce04 Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com>
cgxxv
pushed a commit
to cgxxv/zap
that referenced
this pull request
Mar 25, 2022
Calling `time.Now()` and creating an entry is unnecessary if the underlying core has the specified level disabled. To reduce the cost of logs at disabled levels, skip entry creation if the log level is disabled in the core. This special logic does not apply to DPanic or higher logs as they may need to panic/exit even if the entry does not cause any log to be emitted. On my machine, disabled debugging logs are 6x (~60ns to ~10ns) based on the example in the issue. benchcmp: ``` benchmark old ns/op new ns/op delta BenchmarkDisabledWithoutFields/Zap-12 8.42 1.59 -81.12% BenchmarkDisabledWithoutFields/Zap.Check-12 8.01 1.32 -83.52% BenchmarkDisabledWithoutFields/Zap.Sugar-12 12.4 11.4 -8.06% BenchmarkDisabledWithoutFields/Zap.SugarFormatting-12 117 102 -12.82% ``` Fixes uber-go#770.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Calling
time.Now()and creating an entry is unnecessaryif the underlying core has the specified level disabled.
To reduce the cost of logs at disabled levels, skip entry
creation if the log level is disabled in the core.
This special logic does not apply to DPanic or higher logs as
they may need to panic/exit even if the entry does not cause
any log to be emitted.
On my machine, disabled debugging logs are 6x (~60ns to ~10ns)
based on the example in the issue.
benchcmp:
Fixes #770.