5 ms·
What are the usual cgo issues? I've used it a fair bit and haven't had any general problems. There are specific problems like you can't use syscalls which must
by tych0 6y ago
What are the usual cgo issues? I've used it a fair bit and haven't had any general problems.
There are specific problems like you can't use syscalls which must be single threaded (a royal pain for container managers, since setns() is), but binding to a library like simdjson wouldn't have this problem.
- sk0g 6y agoThere's a latency overhead to cgo calls that isn't really on the list of things to be optimised. Renders the language unusable for wrapping around OpenGL and the likes, in a (complex) gaming context. See issues like this: https://github.com/golang/go/issues/19574 https://github.com/golang/go/issues/19574
- masklinn 6y ago> What are the usual cgo issues? I've used it a fair bit and haven't had any general problems. 1. cgo calls have much higher overhead than regular function calls, so for small documents you'd likely lose performance rather than gain, and even for large ones depending how you read from the parser it might also be terrible, callback-based libraries are even worse as calling Go from C is even slower 2. concurrency can suffer a lot as a Ccall will prevent switching out the corresponding goroutine, locking out a scheduler thread 3. cgo complicates builds, especially cross-compilation 4. it also makes deployments more complicated if you were relying on just synching a statically linked binary 5. might have improved since, but used to be most of the built-in Go development tools couldn't cross the cgo barrier, and non-go devtools generally don't support go