Shaving 40% Off Google’s B-Tree Implementation with Go Generics

Re:Shaving 40% Off Google’s B-Tree Implementation with Go Ge... by jppittma on Tuesday September 19, 2023 @11:11PM (#37580001)

If you care so deeply about memory access that you want control over stack allocation, you probably care enough that you don't want a GC. What's your use case where the GC doesn't murder you, but you care about better cache locality?

[ Parent | on HN ]

Re:Shaving 40% Off Google’s B-Tree Implementation with Go Ge... by adgjlsfhk1 on Wednesday September 20, 2023 @01:11AM (#37580574)

Objects on the stack don't participate in the GC (technically they're GC roots). Half of the reason you want to be able to put variables on the stack is because the stack variables are managed by lifetime and therefore the GC doesn't have to collect them.

[ Parent | on HN ]

Re:Shaving 40% Off Google’s B-Tree Implementation with Go Ge... by thfuran on Wednesday September 20, 2023 @04:17AM (#37581746)

Isn't more explicit control of memory allocation useful precisely in the places where the default behavior would murder you? I don't see the incompatibility. Many python and java programs have portions that are native code for performance reasons (though that's not necessarily just about GC).

What's relatively rare is a program where the whole thing is absolutely performance critical rather than just some parts.

[ Parent | on HN ]