Based on two decades of Java FFI - the overhead comes from type mapping not the housekeeping to control GC. The latter can be as simple as a volatile read and 2 writes per call and can usually be coalesced in tight loops. Since Go already has easy native C type mapping the FFi should be very efficient depending on types used.
> On Mar 14, 2021, at 11:37 AM, Jason E. Aten <j.e.a...@gmail.com> wrote: > > > I'm no authority here, but I believe a large (major?) part of the Cgo > overhead is caused by scheduling overhead. As I understand it, a C function > call is non-preemptible and the Go runtime don't know whether the call will > block. > > But that part would be handled by the C-compiler-that-knows-Go inserting the > pre-emption points just like the Go compiler does into the generated code. Or > the same checks for blocking. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.com.
