Think about more optimal field processing #14

New issue

Open

opened 2023-10-18 08:25:15 +00:00 by fyrchik · 1 comment

fyrchik commented

2023-10-18 08:25:15 +00:00

Owner

Requirements:

Some fields have to be logged only to journal
Some fields have to be logged only to zap (inside the message in the journal)
Some fields have to be logged to both.

The third requirement is the hardest, I had a prototype using SkipType for zap fields in #12, but it doesn't work with (3).
I see two solutions here:

Make the logic in (3) explicit in the caller, thus log 2 fields (once as an "application" field, second as "journal" with SkipType)
Device a clever scheme: zap.Field has 3 fields to carry payload (String, Integer and Interface), at least one of it is always empty. We could use it to carry some form of a mark to determine the field encoding rules.

From the user POV I would like the second but it seems too dirty.

Currently benchmarks in repo show 800ns on my machine, with skip it may become 500ns.

Requirements: 1. Some fields have to be logged only to journal 2. Some fields have to be logged only to zap (inside the message in the journal) 3. Some fields have to be logged to both. The third requirement is the hardest, I had a prototype using `SkipType` for zap fields in #12, but it doesn't work with (3). I see two solutions here: 1. Make the logic in (3) explicit in the caller, thus log 2 fields (once as an "application" field, second as "journal" with `SkipType`) 2. Device a clever scheme: `zap.Field` has 3 fields to carry payload (`String`, `Integer` and `Interface`), at least one of it is always empty. We could use it to carry some form of a mark to determine the field encoding rules. From the user POV I would like the second but it seems too dirty. Currently benchmarks in repo show 800ns on my machine, with skip it may become 500ns.

fyrchik referenced this issue

2023-10-18 08:26:22 +00:00

Optimize encoder #12

fyrchik added the

discussion

label 2023-10-18 08:31:31 +00:00

fyrchik commented

2023-10-18 08:32:44 +00:00

Author

Owner

One note about the first option -- it may provide us the needed optimization, because the slice we provide will become bigger (and thus bigger allocation)