[nicksardo]

Former Google engineer here. My team used the open source Go B-Tree implementation but I replaced it with a non-interface version over a year ago because of performance issues. The lack of generics at the time wasn't a problem because code generation is quite easy via Google's build system.

Replacing interfaces is only part of the performance improvement. When it comes to the B-Tree, you want to improve data locality as much as possible. My implementation also replaced slices with arrays (again using code gen to specify the tree degree). This means each node on the heap literally contained all the keys and, and in some cases, the values themselves. It also helped to split the key/values into separate arrays so all the values didn't interlace the keys.

The insert/retrieval benchmark times compared to the open source version were significantly faster. Since this version relied on codegen, I never bothered to push it publicly. Though, there are tons of B-tree implementations on github, each touting themselves as fastest.

[netheril96]

Go supporters see C++ templates as abomination, yet these performance problems can be easily solved by C++ templates. C++ templates can have integer value in its template parameter, so if we implement that B-Tree in C++, we don't have to resort to codegen at all, as the language is powerful enough.

[DeathArrow]

The two languages have different philosophies. C++ is targeted at performance while Go is intended to be easy to learn.

[gkrimer]

Sadly not public, but for those with access, Nick's deep dive into B-tree performance: go/ganpati-state-mgmt-v7

[skybrian]

It sounds like btree could be further improved with a future version of generics that allows you to pass in array size constants statically?