the double loop in the benchmark looks weird, also it violates the pointer safety rules

the double loop in the benchmark looks weird, also it violates the pointer safety rules

Accepted it and fixed.

What kind of code would use these new functions?

What kind of code would use these new functions?

For example, It allows more fast access to the struct fields by pre-cached offsets.

src := reflect.ValueAt(srcFieldType, unsafe.Pointer(uintptr(srcPtr)+srcOffset))
dest := reflect.ValueAt(destFieldType, unsafe.Pointer(uintptr(destPtr)+destOffset))
dest.Set(src)

Have you attempted to make the current APIs faster?

Also, if you find reflect to be too slow for your use case in general, you could always give up some safety and use more unsafe directly instead of reflect. You appear to be using unsafe pointer arithmetic already.

Have you attempted to make the current APIs faster?

I don't see way to do it. NewAt uses ptrTo and it is very heavy internally.

Also, if you find reflect to be too slow for your use case in general, you could always give up some safety and use more unsafe directly instead of reflect. You appear to be using unsafe pointer arithmetic already.

Go does't have a function that allows to copy arbitrary count of bytes. If some memory copy function were there, it would most likely solve the problem. And one way, that i know, to copy the variable of unknown type is to use Set(), that is required the indirect Value and which can only be obtained in the following way:

src := reflect.NewAt(srcType, srcPtr).Elem() // slow
dest := reflect.NewAt(destType, destPtr).Elem() // slow
dest.Set(src)

With the copy function and a few unsafe casts to array of byte, you can actually copy an arbitrary amount of bytes.

The only difference between this API and the existing API is which type gets passed in.
NewAt(typ, p) == NewAtPtr(PtrTo(typ), p).
And the issue is that PtrTo sometimes requires a map lookup.
But that map lookup is only needed for types that are not themselves already in the binary.
If type T gets reflect information in the binary, then we also write out *T in the binary.
You'd only see this if you constructed T itself at runtime, or if you were using **T or something like that.
What is the context in which this occurs?

If T is constructed at runtime, the data is writable, so we could fill in the *T link once and reuse it instead of using the map.
(That's not true for a *T built into the binary - there we can't write the link to **T.)

So it seems like in whatever important case we have, we could make PtrTo faster instead of adding new API here.

But would that address the case where you are seeing this?
(That is, again, what is the context in which this occurs?)

Change https://golang.org/cl/264237 mentions this issue: reflect: set ptrToThis when asked for pointer to dynamic type

I was curious how hard this would be, so I wrote https://golang.org/cl/264237 to record pointer types in the ptrToThis field of newly created dynamic types. It would be interesting to know what effect this has on the benchmarks here.

Actually that code is slower. Never mind.

Maybe we should re-expand ptrToThis to be a full pointer. I don't know how much this specific field would expand the reflect data.

But the more important question is again, what is the context in which this slow execution occurs? /cc @yazver

Does anyone want to describe a time when the speed of NewAt was too slow?
We think we know how to make it faster but it would be nice to understand what we would be making faster, if anything, to justify the added complexity and slight size overhead.

We think we know how to optimize NewAt if it is too slow. But we need to see a use case to understand the tradeoff there.

On the new API topic (this issue), based on the discussion above this seems like a likely decline.

No change in consensus, so declined.