If FFI calls are slow (even slower than Ruby -> Ruby calls) then informs the way you use native code. You look for workflows whereby frequent calls to a FFI fun

If FFI calls are slow (even slower than Ruby -> Ruby calls) then informs the way you use native code. You look for workflows whereby frequent calls to a FFI function are avoided: e.g. large number of calls in some inner loop. Suppose such a situation cannot be avoided. Then you may have no recourse than to move that loop out of Ruby into C: create a custom FFI for that use case which you can call once and have it execute the loop, calling many times the function you really wanted to call. If the FFI call can be made faster, maybe you can keep the loop in Ruby. Of course that is attractive to people writing an application in Ruby. That's how I interpret keeping as much code Ruby as possible. Nobody in their right mind wants to add additional application-specific jigs written in C just to use some C piece. Once you start doing that, why even have FFI; you can just create a module. One attractive point about FFI is that you can take some C library and use it in a higher level language without writing a line of C.