cmd/compile: avoid convT2E for T = struct{} (empty struct)

[rogpeppe]

go version devel +0b2daa5 Thu Dec 1 11:23:17 2016 +0000 linux/amd64

An empty struct is held in an interface value as a non-nil pointer. This means that
converting an empty struct to an interface is more expensive that
it needs to be be - it involves a call to convT2E.

Given that conversion of empty structs to interfaces is common (for example,
empty structs are often used as context keys) it may be better to use
the nil pointer as the value part of the interface, making
interface{}(struct{}{}) as efficient as interface{}((*int)(nil)).

[minux]

But the current suggested way for context keys is to save it into a variable of type interface{} to reduce the cost of interface conversion? i.e. type contextKey struct{} var SomethingKey interface{} = contextKey{} then the proposed optimization won't be as useful? My concern is just that it introduces a special case to object representation to optimize a case where there already is another user visible way to optimize.

[rogpeppe]

But the current suggested way for context keys is to
save it into a variable of type interface{} to reduce
the cost of interface conversion?

Why should there be any cost to interface conversion of a struct{} ?
By contrast, there's no cost to converting a pointer to an interface and converting
a known-nil pointer to an interface is even cheaper than copying an
interface AFAICS.

ISTM that the suggested workaround should be unnecessary.
It imposes cognitive overhead because you need to invent two
names rather than one, and because by defining it as an interface
variable, you open up the possibility of it being modified.

FWIW the "current suggested way" as seen in https://blog.golang.org/context is
to use a typed integer constant, which is definitely not ideal as it will incur
an allocation every time it's used.

[rogpeppe]

BTW I think the compiler should probably completely optimize out all "struct{}"-valued variables. Using such a variable could be exactly the same as using a struct{}{} literal. Currently different code is generated for:

interface{}(struct{}{})

and

 var x struct{}
 ...
     interface{}(x)

I don't see any reason that there should be a difference.

That should perhaps be considered another issue though.

[randall77]

See also #17725.
We can certainly avoid the convT2E cost in this case. We could use &zerobase (what malloc returns for zero-sized allocations) instead of nil (not sure if it matters, have to think about it).

type contextKey struct{}
var SomethingKey interface{} = contextKey{}

This is a general way to optimize doing the interface construction only once. Optimizing struct{} won't invalidate that whole pattern. But it does become useless for struct{}. I'm ok with that.

[rogpeppe]

We could use &zerobase (what malloc returns for zero-sized allocations) instead of nil

That already seems to be the case. The pointer value in interface{}(struct{}{}) is the same as &struct{}{}.

[randall77]

Right. But we don't need to call convT2E, which calls mallocgc, which then returns &zerobase. We can just use &zerobase directly.

[randall77]

(Why did this reply not appear on the issue? Weird.)

On Wed, Dec 21, 2016 at 9:41 AM, Chris Stockton ***@***.***> wrote: Hello, I believe the performance differences I mention are due to workload on the GC. This workload is not related to the representation of the values when assigned to an interface, it's how (lifecycle of) they are assigned. The efficiency of interface{}(struct{}{}) is as efficient as interface{}((*int)(nil)) for assignment operations. Both will reuse the same address each time, meaning this is unrelated to #17725 <#17725>. The issue here is the GC has to take ownership when type TypKey struct{} is moved to the heap. This may be easier explained in a butchered SSA form.

This is true of all interface{} assignments. They are just the move of two words, regardless of the type of thing in the interface{}. This issue (and 17725) are only about constructing the interface{}. This issue in particular has nothing at all to do with GC (17725 does). We aren't allocating anything for interfaces containing zero-sized objects. But we are calling convT2E + mallocgc unnecessarily, which I believe is the core of this issue. Unless you think that nil vs &zerobase affects the work GC has to do? I don't think that is the case.

…

When using a struct literal such as context.WithValue(ctx, TypKey{}, val). t1 = local TypKey t2 = *t1 t3 = make interface{} <- t2 t4 = context.WithValue(t0, t3, ...) When using an addressable value on the heap, context.WithValue(ctx, VarKey, val)`. t1 = *VarKey t2 = make interface{} <- t1 t3 = context.WithValue(t0, t2, ...) I can't think of a way this could be avoided without a SSA pass that detects empty composite literals and allocates a single address for each T in a scratch space, only when T is a empty struct. I may be way off here, but I wanted to clarify a bit. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18402 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGkgIEA9h_zN2QRnfK6iqpNj32v85JzPks5rKWS4gaJpZM4LSytq> .

[cstockton]

@randall77 I deleted the post after I made it, I was thinking the conversation was headed around higher level assignment semantics, this makes sense I think:

Right. But we don't need to call convT2E, which calls mallocgc, which then returns &zerobase. We can just use &zerobase directly.

[iand]

As an additional data point golint checks basic data types for suitability as context keys and explicitly OK's struct{} (golang/lint#245)

[josharian]

Gophetbot still seems ill, so: CL 35562

[gopherbot]

CL https://golang.org/cl/35562 mentions this issue.