| Thank you author for your kind words about my Go SQLite driver. That said, purego solves a build infrastructure issue, not a perfomance issue. You're still using the same underlying mechanisms to call into C, and the same performance is expected. I'm not the one saying this, read the authors: https://github.com/ebitengine/purego/issues/202 wazero uses a different mechanism, the one used to call Go assembly, but adds its own overhead (trampolines, adapting calling conventions, and the inherent Wasm sandbox overhead, e.g. the guest can't read the host's memory, there's bounds checks, etc). Also “Cgo is fast” and “Cgo is slow” is not the correct framing; rather it depends, for various reasons: - Cgo is a moving target (it mostly improves with time, but can regress) - it's different to just call C from Go, or then callback Go from C - there's not just call overhead to consider, but also scheduler overhead which is much harder to measure consistently |
Yup you are absolutely right. My thought was that my next post would dive into exploring whether or not this actually solved any of the issues listed about CGO. I updated the post to be a little more clear.