reflect: Type.Field allocates

[rsc]

it's the only thing in Type that allocates.  avoid.

    f.Index = []int{i}

[rsc]

Comment 1:

Labels changed: added priority-later, removed priority-medium.

[rsc]

Comment 2:

Labels changed: added priority-go1.

[remyoudompheng]

Comment 3:

Why is StructField.Index a slice ? It would make sense if FieldByIndex([]int) would
actually return the same slice argument in the Index field, but it seems it is not the
case and it always returns a slice of length 1 there.
Is it for embedded structs ?

[rsc]

Comment 4:

Yes, it is because FieldByName returns a Field with a slice in it.

[robpike]

Comment 5:

Owner changed to builder@golang.org.

[bradfitz]

Comment 7:

http://golang.org/cl/5564066

Owner changed to @bradfitz.

Status changed to Started.

[bradfitz]

Comment 8:

Also, Russ's earlier version with read-only memory:
http://golang.org/cl/5371098
Pushing out past Go1.  No super compelling argument for it.

Labels changed: added priority-later, removed priority-go1.

Owner changed to builder@golang.org.

[rsc]

Comment 9:

Labels changed: added go1.1.

[rsc]

Comment 10:

Labels changed: added size-m.

[rsc]

Comment 11:

Per discussion on https://golang.org/cl/5371098, we've decided the drawbacks
outweigh the benefits. If the pendulum ever swings back, the CL is there.

Status changed to WorkingAsIntended.

[bprosnitz]

Just want to leave a comment on this. This makes up about a third of the allocations for my team's encoder and decoder and has a major impact on performance. I looked into alternative strategies to solve this in type.go, but concluded that it isn't possible to have a satisfying solution so long as the index field is a slice and wanted to leave a note.

It isn't possible to back the slice by the stack (say by an unexposed array in the struct) because escape analysis (correctly) will detect that due to the return, the backing array of the slice must be on the heap. Once the slice must be backed by the heap, the only way to reduce allocations is to reduce the number of them. This isn't possible because we would either back the slice by constants (which breaks the semantics of being able to modify the returned value) or back it by an array that is shared across method calls (which is bad for a number of reasons).

[minux]

Backing the slice with an unexported array in the struct won't work,
this has been suggested in https://golang.org/cl/5371098.

I think writable poitners to read-only memory are a bad idea. The best
idea I can have is make StructField.Index a slice of a hidden
StructField.index [4]int so that it doesn't escape and cover most cases.
This doesn't work: assignment of a StructField value will not update the
slice, and now you have a slice pointing back into the original StructField.