s.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/002d5e0d-2469-4f15-8eb0-e8bdc67419f8%40googlegroups.com.
--
Adrian Ratnapala
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
ving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUdMiJLvdfYe9%2B7fzjeuwJtu6uGxmW3UE-%3D%2BZ2DQLU%3D1Q%40mail.gmail.com.
--
Adrian Ratnapala
--
You recei
s are a surprise, at least to me. Here are the results when Count = 8:
>>
>> Benchmark1-4 2706196 442 ns/op
>> Benchmark2-4 1357482 873 ns/op
>> Benchmark3-4 840729 1387 ns/op
>> PASS
>> ok bar.com/benchm
into the documentation? And if so, where (in package
fmt or errors)?
Lots of programers will assume that because %w is new, then it must be
the Go team's recommended "best practice". I think I was unconciously
thinking that until I read the blog post.
--
Adrian Ratnapala
--
You r
API in the
> future, you shouldn't wrap the error.
Given the preference for *not* introducing APIs, doesn't that mean
authors should stick to "%v" until they have clear reasons for using
"%w". After all, it's always possible to switch to "%w" later
l could be appropriate, I'll
You could have two separate pools, one for each size. This is
basically a bucketed-allocator, but simpler because you already know
the structure of your buckets.
--
Adrian Ratnapala
--
You received this message because you are subscribed to the Google Groups
&q
> >
> > Any particular reason you avoided something like sync.Pool ? It could
be useful in your case, allocation pattern depending.
> >
> Hi,
>
> I initially evaluated the sync.Pool then I read this article:
>
> https://dzone.com/articles/memory-pooling-in-go-where-why-and-how
>
> and this issue
