On Mon, 26 Nov 2018 at 14:16, Arkady <lary...@gmail.com> wrote:
> ZAP is significantly slower than what I do. The binary log has an inherent
> edge.
AFAIK there is nothing about zap which precludes it from writing binary
files.
Unlike zap, your scheme will inherently incur more memory allocations, as
it takes a memory allocation to put a non-pointer value into an interface
(that's the reason why zap is designed the way it is), so I suspect it will
end up slower in more realistic scenarios.
For comparison call to Log() is 3x faster than fmt.Fprintf()
>
At least fmt.Fprintf works predictably and reliably on all Go
architectures. Correctness is more important than speed. I'd suggest
starting with a more complete solution and making it work before trying to
optimise the heck out of it.
cheers,
rog.
I have added BenchmarkSingleIntRogerPeppe() - 13ns more
> On Mon, Nov 26, 2018 at 4:09 PM roger peppe <rogpe...@gmail.com> wrote:
> >
> > On Sun, 25 Nov 2018 at 19:17, <lary...@gmail.com> wrote:
> >>
> >> These are great tips! Thank you!
> >> This is the context for the code above
> https://github.com/larytet/binlog/blob/master/binlog.go#L548
> >
> >
> > I took a look at this code. It seems that you have a deep understanding
> of how the runtime works, but to me it really seems like you're prematurely
> optimising here, and running serious risk of broken code. The code is full
> of unsafe and non-portable operations that will almost certainly break in
> the future. For example, reading /proc to determine the base offset for
> static strings is... inadvisable.
> >
> > Just because you know what's going on under the covers doesn't mean that
> you should write code that relies on that information.
> >
> > If you want to see a highly performant logging implementation that does
> not seriously rely on unsafe practices, I'd encourage you to take a look at
> the zap package (https://godoc.org/go.uber.org/zap).
> >
> > By the way, your SingleInt benchmark is misleading. You're using a
> constant argument to Log, which means that the runtime can use a single
> interface value for every call, with no allocation required. If you change
> the loop so that it passes a different number each time:
> >
> > for i := 0; i < b.N; i++ {
> > binlog.Log(fmtString, i)
> > }
> >
> > you are likely to find that the performance gap is considerably smaller.
> >
> > cheers,
> > rog.
> >
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
