Closed osmaczko closed 4 days ago
:grey_question: | Commit | :hash: | Finished (UTC) | Duration | Platform | Result |
---|---|---|---|---|---|---|
:heavy_multiplication_x: | 6135d64b | #4 | 2024-11-21 15:49:34 | ~4 min | tests |
:page_facing_up:log |
:heavy_check_mark: | 6135d64b | #4 | 2024-11-21 15:50:05 | ~4 min | linux |
:package:zip |
:heavy_check_mark: | 6135d64b | #4 | 2024-11-21 15:50:31 | ~5 min | ios |
:package:zip |
:heavy_check_mark: | 6135d64b | #4 | 2024-11-21 15:50:31 | ~5 min | macos |
:package:zip |
:heavy_multiplication_x: | 6135d64b | #4 | 2024-11-21 15:50:34 | ~5 min | tests-rpc |
:page_facing_up:log |
:heavy_check_mark: | 6135d64b | #4 | 2024-11-21 15:50:40 | ~5 min | windows |
:package:zip |
:heavy_check_mark: | 6135d64b | #4 | 2024-11-21 15:50:48 | ~5 min | macos |
:package:zip |
:heavy_check_mark: | 6135d64b | #4 | 2024-11-21 15:51:09 | ~5 min | android |
:package:aar |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:20:30 | ~3 min | windows |
:package:zip |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:20:37 | ~3 min | macos |
:package:zip |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:20:53 | ~4 min | tests-rpc |
:page_facing_up:log |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:21:09 | ~4 min | ios |
:package:zip |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:21:54 | ~5 min | macos |
:package:zip |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:22:24 | ~5 min | linux |
:package:zip |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:22:57 | ~6 min | android |
:package:aar |
:heavy_check_mark: | e5e053bd | #5 | 2024-11-21 17:49:29 | ~32 min | tests |
:page_facing_up:log |
Attention: Patch coverage is 82.00000%
with 9 lines
in your changes missing coverage. Please review.
Project coverage is 60.92%. Comparing base (
11cf42b
) to head (e5e053b
). Report is 5 commits behind head on develop.
Files with missing lines | Patch % | Lines |
---|---|---|
logutils/core.go | 82.00% | 6 Missing and 3 partials :warning: |
Noice 👍 Is this not too harmful for performance?
Thanks! Overriding the log level, format, and writer isn’t a common operation—usually it's done only once per user account lifetime—so I wouldn’t worry about performance here. As for the writes, since I used atomics, performance should be solid (no locks on write from multiple goroutines). I’ll look into creating a benchmark.
no usage for the custom zap.Core yet?
There is a followup PR I am finalizing: https://github.com/status-im/status-go/pull/6025/
@igor-sirotin created a benchmark for zap.Core and custom core. Result looks fine, seems there is no performance penalty due to use of atomics.
$ go test -bench .
goos: linux
goarch: amd64
pkg: github.com/status-im/status-go/logutils
cpu: AMD Ryzen 7 4800HS with Radeon Graphics
BenchmarkCustomCore-16 1061532 1118 ns/op
BenchmarkZapCore-16 1000000 1057 ns/op
Geth logger allows overriding the log level, format and writer at runtime. To make it interchangeable with zap.Logger, a custom zap.Core has been introduced to enable these features as well.
closes: #6023