Ultra-fast, eminently lossy NullEncoder

[billf]

No description provided.

[prashantv]

Since there's no options or any customizations for this encoder, does it make sense to just have a single global instance and remove the NewNullEncoder constructor?

var NullEncoder Encoder

func init() {
  NullEncoder = nullEncoder{}
}

(I like to separate the declaration from the assignment so that the = nullEncoder{} doesn't show up in the godoc)

[akshayjshah]

I like that approach too. One thing to consider is that it'll make the GoDoc output a little less nice - with a constructor function, all the different encoder constructors are grouped under the Encoder type. Top-level vars are in a completely different section.

[prashantv]

Good point, maybe just func NullEncoder() Encoder then? It'll still be backed by a global by it will show under the Encoder type?

[prashantv]

My new favourite encoder (after all, it's the fastest, and has the least code).

Can we add unit tests to avoid the coverage drop (I can't imagine the tests being too exciting unfortunately, but at least we can make sure that nothing was written to the writer no matter which method is called).

I'm also curious what the benchmarks are! This will give us numbers on just the function call / arg passing overhead compared to the actual work we do in our real encoders.

[billf]

BenchmarkStandardJSON-8                  1000000              2647 ns/op
BenchmarkZapJSON-8                      10000000               254 ns/op
BenchmarkZapNull-8                      100000000               14.5 ns/op

BenchmarkJSONLogMarshalerFunc-8         10000000               122 ns/op
BenchmarkNullLogMarshalerFunc-8         30000000                43.2 ns/op

[prashantv]

can drop comment here too, since it doesn't actually copy the encoded data etc

[prashantv]

lgtm, thanks for adding the benchmarks. BenchmarkNullLogMarshalerFunc is more expensive than I expected, it looks like all it does is:

• get a reference to an existing global null encoder
• call 2 functions which do nothing, but through interfaces (so there's some vtable overhead)

However, since we're using LogMarshalerFunc, it allocates a closure to capture the reference to i. That allocation ends up taking most of the time.

[billf]

should we pull LogMarshalerFunc out of both the json and null encoder and instead use a struct implementing LogMarshaler allocated outside of the benchmark loop?

since LogMarshalerFunc's implementation cannot ever optimized further, i don't see a reason to benchmark it after such a removal.

[prashantv]

Let's merge this as is, and we can move out the LogMarshalerFunc benchmark separately.