-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ultra-fast, eminently lossy NullEncoder #133
Conversation
// nullEncoder is an Encoder implementation that throws everything away. | ||
type nullEncoder struct{} | ||
|
||
// NewNullEncoder creates a fast, no-allocation encoder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, maybe just func NullEncoder() Encoder
then? It'll still be backed by a global by it will show under the Encoder
type?
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. |
|
func (nullEncoder) AddMarshaler(_ string, _ LogMarshaler) error { return nil } | ||
func (nullEncoder) AddObject(_ string, _ interface{}) error { return nil } | ||
|
||
// Clone copies the current encoder, including any data already encoded. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can drop comment here too, since it doesn't actually copy the encoded data etc
lgtm, thanks for adding the benchmarks.
However, since we're using |
should we pull since |
Let's merge this as is, and we can move out the |
No description provided.