I’m not sure if you were getting at this by mentioning the ABI specifically, but for Go the “faster size class computation” isn’t purely about the computation itself.

There are lots of cases in the allocator that are conditional on size class (tiny allocations have a bunch of special cases, as do large allocations). Pointer/no-pointer allocations also have lots of special cases.

In the specialized functions, these conditionals become constant and lots of code falls away. We don’t pay the cost for those comparisons anymore, plus since code size is smaller it is now more reasonable to inline callees a bit more aggressively.

Michael also put a lot of time into finding the right balance of code size. At first you want to specialize everything, but that is going to increase code size a lot and thus hurt icache performance. If I recall correctly, our initial version had a code size increase ~4x higher than what we ended up with in 1.27. The final version specializes far fewer size classes yet actually had better performance than the original version.

Regarding the ABI, we definitely see an improvement with static calls vs computing the size class in the runtime. If I recall correctly, it’s the indirect call to the specialized function through a lookup table that stalls the dynamic case.