How Interface Values Work

Output:

main.Order false
*main.Order true
Copy

The first line reports the copy that was made before order.Paid changed, and the second reads through the pointer to the original. This is the same difference that Value and Pointer Semantics described, now with an interface as the holder.

Ordinary code cannot change the copy inside an interface value, because Go gives no way to take its address. An assignment can only replace it with a new value. This is also the reason a method with a pointer receiver is not available on the stored value. If IsPaid had a pointer receiver, the compiler would reject the first assignment:

./main.go:18:24: cannot use order (variable of struct type Order) as Payable value in variable declaration: Order does not implement Payable (method IsPaid has pointer receiver)
Copy

The copy usually goes to the heap. Stack, Heap, and Escape Analysis explained that cost and how to see it, and the measurement below applies it to the types here.

Output:

store Order:  1
store *Order: 0
Copy

Storing the pointer needs no new memory. Storing the value costs one allocation, because sink outlives the function and must refer to a stable copy. An interface value that stays inside one function can often avoid the allocation, since escape analysis applies here too.

Some non-pointer values also avoid it in Go 1.27. A map, a channel, a function, and a struct with one pointer field are each a single pointer in memory, so they are stored directly in the data word. For an integer from 0 to 255 or an empty string, the functions convT64 and convTstring in runtime/iface.go point the data word at fixed memory that already exists.

Calling a Method

A call through an interface must find the method at run time. The small function below shows the instructions that the compiler produces.

//go:noinline
func check(p Payable) bool { return p.IsPaid() }
Copy

go build -o main main.go
go tool objdump -s main.check ./main
Copy

The output, trimmed to the call and with the addresses removed:

MOVQ 0x18(AX), CX
MOVQ BX, AX
CALL CX
Copy

The two words of p arrive in the registers AX and BX. The first instruction reads the method address from byte 24 of the itab, which is where Fun starts. The second instruction makes the data word the receiver, and the third calls the address that was read. Compared with a direct call, this adds one memory read and makes the call go to an address held in a register (an indirect call).

The data word is always passed as the receiver. For a value type such as Order, the table therefore holds a small generated function, (*Order).IsPaid, which reads the Order through the pointer and then runs the method. Disassembling that function with go tool objdump shows it marked <autogenerated>.

The program below measures this cost. The inlined line calls a method whose body the compiler copies into the loop, and the direct line calls a method that the compiler is not allowed to inline. The interface line calls through a package variable, so the compiler cannot prove which type it holds.

One possible output (measured on one machine):

inlined    0.4 ns
direct     1.1 ns
interface  1.3 ns
Copy

On this machine, the interface call cost 0.2 ns more than a direct call that was not inlined. The numbers include the loop itself, so the differences between lines matter more than the totals. At that difference, one million calls per second would use 0.2 ms of each second, which is 0.02 percent of one CPU core.

The larger effects are indirect. The gap between inlined and the other two lines shows the first one, since a method called through an interface usually cannot be inlined. The second is that the compiler cannot determine which method body will run, so it must assume that pointer arguments escape. The program below counts the result for a method that takes an *Item.

Output:

direct:    0
interface: 1
Copy

The compiler removes this cost when it can prove the dynamic type. It then replaces the indirect call with a direct one (devirtualization). For var p Payable = &order followed by p.IsPaid() in the same function, go build -gcflags=-m reports this:

./main.go:19:22: devirtualizing p.IsPaid to *Order
Copy

An interface call rarely deserves attention on its own. It matters inside a loop that a CPU profile (a record of where a program spends its time) has already identified as slow.

Comparing Interface Values

Two interface values that are not nil are equal when their dynamic types are identical and their dynamic values are equal. The functions efaceeq and ifaceeq in runtime/alg.go perform the second check, after the comparison of the first words has shown that the types match. Each type's own rule then applies, so pointers compare by address and structs compare field by field.

Output:

same type, equal values: true
pointers to equal values: false
int64(1) and int(1): false
Copy

The compiler accepts == on two values of the same interface type, because their dynamic types are not known until the program runs. It rejects == only when neither operand can be assigned to the other's type, such as an io.Reader and an io.Writer. That leaves one failure that only appears at run time. If both values have the same uncomparable dynamic type, such as Order with its slice field, the comparison panics.