3 ms·
The cause of this is not a technical limitation of "this is not possible" but rather "Go does this poorly due to tradeoffs* it insists on". C# trivially pins o
by neonsunset 2y ago
The cause of this is not a technical limitation of "this is not possible" but rather "Go does this poorly due to tradeoffs* it insists on".
C# trivially pins only select buffers or other data that need to be observed by whatever it is being called across FFI while GC is free to move and handle everything else (or, should the data need to be marshalled, it can be stack-allocated and pointer to such is passed instead, or it can be malloc and freed just like you can do in C). Years of work in this area made the impact of FFI as minimal as possible, with extra levers available to the user to completely erase the overhead (suppressing GC frame transition, using methods to allocate objects on the dedicated pinned heap, static linking for aot binaries, etc.).
Go's GC implementation is comparatively simple and has other inefficiencies such as very expensive write barriers.
*sometimes the tradeoff is just a product, which Go is, that was cheaper to produce, despite common beliefs
- raggi 2y agoYup, and far too much spinning going on in the runtime too.