Hacker News Reader

Comment by leononame | Hacker News Reader

Does anyone know: Is there actually a better way in go?

I've heard a couple of times that C Bindings in go are slow. Is this what is usually referred to?

The cost of calling is slow. The C code itself runs at, well, C speed.

So if you're writing a system in both, it's best to have the C side do a lot in each call, vs having the Go side call a lot of tiny funcs.

As far as I remember, there's a lot of machinery involved to make a C call because C doesn't know anything about Go's goroutines and their resizable stacks. So the runtime has to prepare the stack accordingly every time you make a call - and it's done on a dedicated CGO thread with a traditional stack.

That’s a misconception that cgo is slow, it’s improving and it’s not slow, when it comes to stacks, Go with its resizable stack and it’s concurrency it’s not hard to say that it’s very much Go is different from other languages. From a normal C function call that returns immediately there’s not much over head BUT when C function takes time with the runtime expecting return value, the runtime will try to align with the C stack creating a more traditional stack, I think there’s a proposal for a directive to let the compiler know there’s no need for the runtime to wait

Isn't it the opposite? cgo calls always have to switch to a larger stack (because there's no way to know in advance how much stack a function will use, and C functions don't support dynamic stack switching like Go functions do), so they have some fixed overhead per call. And that fixed overhead is most significant in relative terms when the call returns quickly.

I stand corrected I don’t know much about Go’s runtime, it’s complicated that following it gives me headache

The better way is to call free manually, instead of relying on a finalizer.

If you're only calling cgo in a few places, it's not too hard to check each one for memory leaks.

Reply on news.ycombinator.com