5 ms·
There are many years since the article being written. I'm wondering if there is a better solution in 2024.
by zxilly 2y ago
There are many years since the article being written. I'm wondering if there is a better solution in 2024.
- ozgrakkurt 2y agoDoesn’t seem like there is. Probably because go developers want code to be pure go if possible
- mappu 2y agoCgo overhead was made 5-30x faster in go1.21, and it was already within noise levels in this article, so i'd use that.
- chabad360 2y agoCan you provide a reference for that? A quick search for me didn't bring up anything. I'm curious to read more.
- lossolo 2y agohttps://shane.ai/posts/cgo-performance-in-go1.21/ https://shane.ai/posts/cgo-performance-in-go1.21/
- mananaysiempre 2y ago> Cgo calls take about 40ns, about the same time encoding/json takes to parse a single digit integer. As an aside, that sure feels like a lot of time to parse a single-digit integer. Not catastrophic by any means, but still, 100 to 200 cycles is a sign the program is definitely Doing Something. Perhaps that’s the memory allocator?
- ecnahc515 2y agoIt's probably just because it's using reflection which is pretty slow in general. Lots of conditions/branches and boxing/unboxing of values.
- benmmurphy 2y agothey changed the ABI in 1.17 to pass arguments in registers instead of the stack: https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.17#compiler so if you used this solution you might not need to do the fixup anymore if the ABI matches.