ymz-ncnk

First, it should be said that we are talking about the unsafe package. Secondly, the behavior (unsafe behavior) you mentioned ⚠️ will be true not only for a string type,...

With this approach, we can get zero allocation deserialization. But it turns out that it is not very useful and we do not want to measure such cases? > You...

If some results were obtained using an unique feature, we can simply label them with the appropriate name. Wouldn't that solve the problem? Perhaps over time, other competitors will also...

Well, I'm trying to propose a solution. And there is already a similar issue - https://github.com/alecthomas/go_serialization_benchmarks/issues/120.

It turns out that it's not enough to call a package and the results it produces unsafe. I'll try to improve the MUS documentation and also add a comment to...

Just to be clear. Let's look at two cases. First one: ```go for { bs := ReadData() // Each time ReadData() returns a new bs! We can choose // this...

> However @ymz-ncnk doesn't accept my point yet, But fortunately he fixed the bug and current version hasn't that bug. > > old versions were using the following these three...

> > Just to be clear. Let's look at two cases. First one: > > ```go > > for { > > bs := ReadData() // Each time ReadData() returns...

I don't want to disappoint you, but this is still true even now (and this is not how the unsafe package should be used): ```go func TestUnsafe(t *testing.T) { bs...

> A reasonable solution is to have two benchmarks and name them appropriately so that users can make distinguish between them. How about we stop discussing it and someone sends...