4 ms·
Depends how you use it, just last week I’ve hit 40 nanoseconds unpacking a 8 megabyte msgpack array and accessing one of its values in a hash. As long as you o
by Asmod4n 1y ago
Depends how you use it, just last week I’ve hit 40 nanoseconds unpacking a 8 megabyte msgpack array and accessing one of its values in a hash.
As long as you only use ruby as glue code for c(++) extensions it’s pretty fast.
- norman784 1y agoAFAIK with the latest JIT in some contexts pure Ruby can be faster than using C libraries, just because the VM can be better optimized and there is no overhead in moving data between the two realms. I don't recall exactly where I read it, but I think was a while ago when they announced one of the newest JIT engines.
- Alifatisk 1y agoI recall something similar statement and I think it was from the YJIT team, they suggested that more and more people write pure Ruby rather than using C extensions because the YJIT compiler cannot see C code, it's like a black box to it, so it cannot optimize it further. Which means that in practical examples, YJIT has been able to optimize pure Ruby code to the extent that it in some cases not only beat the C extension but also surpassed it More Ruby code means more room for optimizations that the team can identify and add to the compiler
- Someone 1y agoPossibly https://railsatscale.com/2023-08-29-ruby-outperforms-c/ https://railsatscale.com/2023-08-29-ruby-outperforms-c/ or https://jpcamara.com/2024/12/01/speeding-up-ruby.html https://jpcamara.com/2024/12/01/speeding-up-ruby.html
- igouy 1y agoSo you don't actually know?
- IshKebab 1y ago> As long as you only use ruby as glue code for c(++) extensions it’s pretty fast. Another way of saying that is "as long as you don't use it it won't slow you down".