babashka 2026-08-28

How courageous to already benchmark bb.ffi while it's being developed. For bb.ffi it heavily depends what you are measuring. Some calls will be super fast, other won't since they have to fall back on libffi. I'm going to check out your bechmarks to learn more.

That's totally fair! I just wanted to get it in because I was doing another round of updates to that benchmark which I only update once in awhile. (And I thought you might be interested) Also, I hope you didn't interpret this as being a jab! That wasn't my intention. I'm well aware it's still pre-release. Happy for any feedback you might have.

I already have the answer. you're mostly measuring bb/SCI interpreter overhead here, not FFI overhead. Since you're doing a call in a 500M loop, this will be slow because of the interpreter, not because of FFM

I'll try to rewrite the benchmark with run!

if you want to measure FFI overhead you'll have to run the same loop without the FFI calls and then subtract the timings, or rewrite the loop in terms of host stuff like run!

in most realistic FFI lib scenario's you won't be calling the lib 500M times in a short time though, you will let the lib do the hard work instead