Conversion of small integer values to the interface now occurs without allocations.In this short post I will tell you what the optimization is.
How interface {} works in Go
To understand how this optimization works, you need to brush up on the interface {} device in Go. I will not dive into this topic too much, just recall the main ideas.
Inside src / runtime / runtime2.go there is a structure like this:
type iface struct {
tab *itab
data unsafe.Pointer
}
This is our interface. In fact, interface {} is only 2 pointers:
- data - a pointer to the data itself for which the memory was allocated on the heap
- tab - meta information about the interface and base type
We visualize the knowledge gained and move on.
What is the actual problem
In Go, allocating new objects in hip is expensive. Therefore, if you want to write productive code, then you will definitely face this problem. So any, even at first glance, minor optimizations can improve the performance of the entire application.
The problem that the considered optimization solves is that it is a wasteful undertaking to allocate objects for small integers.
How was it solved
Here's what the guys at Go did. In the runtime package, they already had a static array of integers from 0 to 255. At the moment when an integer is converted to interface {}, a check is made whether this number is in the specified range, and if so, a pointer to an element in this array. This eliminates unnecessary allocation.
You can see the changes on the gihab .
These kinds of optimizations are not new in Go. So, if you create a one-character ascii string, there will be no memory allocations. There will not be all of them according to the same scenario: the Go runtime contains a static array of single-character strings. By the way, don't worry, as nowadays only one static array of values from 0 to 255 lives in runtime. It is reused for string representations.