On Tue, Dec 29, 2020 at 4:37 PM Arnaud Delobelle <arno...@gmail.com> wrote:
> Question 1: I *think* that the compiler has all the information necessary
> to implement type assertion to the Cont interface as I have, i.e. it knows
> only 3 types implement that interface, so could it not do the optimisation
> on my behalf?
>
>
Question 2: Or is it possible that other Go values can be made at runtime
> that would implement this interface but not be one of the three known types
> that implement it?
>
Yes, re 2. `reflect` can create new types at runtime. AFAIK the
implementation for interface-type-assertions is basically to look it up in
a global hashmap, which is pre-seeded with compile-time known types and
then gets filled on each (successful) inteface-type-assertion with the
correct method tables. But, I'm handwaving.
Under these assumptions, it might be *possible* to first check against the
statically known types and only fall back on the map if none of that
matches. But it doesn't seem 100% clear to me that that's always faster.
I think concrete type-assertions will always be faster than interface
type-assertions though - for a concrete type-assertions, it's really just
comparing the two type-pointers and copying the value (which, in your case,
is a pointer itself), whereas for an interface type-assertion, the actual
method table must be assembled or looked up.
But, here's a question: If `v.iface` always contains a `Cont` - at least
that's what I assume from the fact that you don't use a ,ok assertion - why
not just declare it as such, instead of `interface{}`?
Question 3: Is it possible that there is something dodgy going on with the
> benchmarks, with some code being optimised away - if so, how can I check
> that?
>
Sorry, no idea.
>
> Thanks in advance for any insights!
>
> --
> Arnaud
>
> [1] https://github.com/arnodel/golua
>
> [2] Definition of the Cont interface type:
> type Cont interface {
> Push(Value)
> PushEtc([]Value)
> RunInThread(*Thread) (Cont, *Error)
> Next() Cont
> DebugInfo() *DebugInfo
> }
>
>
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/efcf0a84-4e7d-4241-9f5a-994774a7f14dn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/efcf0a84-4e7d-4241-9f5a-994774a7f14dn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGhbAq5CS%2BG1VZJose%2BYLWncqFiFzKZQdXVmL22oFx_Ng%40mail.gmail.com.
