3 ms·
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 ha
by Patrickmi 3y ago
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
- comex 3y agoIsn'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.
- Patrickmi 3y agoI stand corrected I don’t know much about Go’s runtime, it’s complicated that following it gives me headache