On Tue, Feb 17, 2015 at 8:52 AM, thwd wrote:
* some named types are added to .typelink, although they're not supposed to
according to comments in cmd/gc/reflect.c
That sounds like a bug that should be fixed. There is no reason to
put a named type into the typelinks. If possible, please file an
issue with a reproduction. Thanks.
* there's one big typelinks slice shared by runtime with reflect
(runtime.reflect_typelinks() in runtime/runtime1.go linked as
* typesByString uses a binary search in combination with a linear one
Yes, although the linear search is likely to be quite short.
* fix code to only export unnamed (composite) types.
* split typelinks slice into separate typelink-containers for funcs,
channels, maps, slices, structs, and so forth.. 1 per kind
I don't see a big advantage to doing this. Those different types are
all automatically segregated in the typelinks slice anyhow, since they
will be sorted separately.
* make each typelink-container a map[string]*reflect.rtype
* typesByString uses map access
My approach would be to leave runtime.typelinks() as-is and build the
typelink-container maps in the reflect package's init() method. Reason being
that in the contrary case I'd have to add to cmd/gc/reflect.c and I believe
that we're trying to get away from C in the runtime . Besides, I'm
unfamiliar with the C codebase.
We definitely don't want to do anything like this in the reflect
package's init method. Approximately every program uses reflect.
Approximately no program looks at typelinks. We don't want to
penalize the startup of every program for the benefit of no program.
The question is whether this is worth doing for the case of a program
that actually does need the typelinks. My guess is that it is not.
Even programs that use typelinks probably don't use it very much.
Although approximately no program uses typelinks, should we slow down
the programs that do use it for the benefit of programs that use it a
lot? My intuition is that it's better to keep things simple. But if
you have a counter-example, please present it. A counter-example
would be a program that calls SliceOf, etc., a lot with a lot of
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.