For your sliceinsert microbenchmarks, you don't provide the Go version, you
don't provide memory allocation statistics, and you only provide results
for a single data point.
My results for several values of N:
https://play.golang.org/p/WuKmIy_jY20
There are significant differences in CPU
For your sliceinsert microbenchmarks, you don't provide the Go version, you
don't provide memory allocation statistics, and you only provide results
for a single data point.
My results for several values of N:
https://play.golang.org/p/WuKmIy_jY20
There are significant differences in CPU
With go version go1.16.3 darwin/amd64 (macOS 10.14.6), and after changing
N/5 to N/2, I can't reproduce either.
$ go test . -bench=. -benchtime=3s
N = 1615119
goos: darwin
goarch: amd64
pkg: bm
cpu: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
Benchmark_InsertOneline-4
Generally, I would argue that the grpc package maintainers should, at some
point, support native wrapping of errors.
In the meantime, they are providing this package:
https://pkg.go.dev/google.golang.org/grpc/status
It predates (by a long time) the errors.Is APIs, which is why I assume they
On Sat, 2021-05-15 at 04:47 -0700, cpu...@gmail.com wrote:
> In my local code, I'm using things like
>
> if errors.Is(err, api.ErrMustRetry) { ... }
>
> How would I achieve the same on errors returned by the gRCP
> interface? I've noticed these are wrapped:
>
> rpc error: code = Unknown desc =
In my local code, I'm using things like
if errors.Is(err, api.ErrMustRetry) { ... }
How would I achieve the same on errors returned by the gRCP interface? I've
noticed these are wrapped:
rpc error: code = Unknown desc = must retry rpc error: code = Unknown desc
= must retry
I assume the
Robert :)
> On May 15, 2021, at 3:48 AM, Øyvind Teig wrote:
>
> Thanks, rog. I appreciate this! Even if I cant' stop thinking that a "pri"
> would have been sligtly more elegant. But you shall be praised for the try! I
> wont' take the time to fine read the code, though...
>
> ..Aside:
Thanks, rog. I appreciate this! Even if I cant' stop thinking that a "pri"
would have been sligtly more elegant. But you shall be praised for the try!
I wont' take the time to fine read the code, though...
..Aside: Being more than busy to digest the fact that XMOS has announced a
paradigm
