The title says it all, what are the trade offs between ffi and mri c extensions in ruby?
+2
A:
One obvious tradeoff is that MRI C extensions only work on MRI, whereas FFI extensions work on MRI, YARV, Rubinius and JRuby at the moment, and will in the future probably also work on IronRuby, MagLev, MacRuby, SmallRuby, tinyrb and RubyGoLightly.
Jörg W Mittag
2010-09-08 17:52:05
right, but do you lose anything by using FFI instead? What is traded for that portability, if anything?
jshen
2010-09-08 19:24:40
@jshen: The main thing you lose is that there are no boundaries between the interpreter and the extension. An MRI C extension can access and manipulate every single byte of private internal memory of the interpreter. This is not possible with FFI, a) because the API doesn't support it and b) because obviously the private internal data structures of JRuby are vastly different from MRI, so it cannot possibly work anyway. Note that this is actually a good thing: this tight coupling is actually the single biggest obstacle to a faster MRI, because even the tiniest change will break many MRI exts.
Jörg W Mittag
2010-09-08 22:00:09
+1
A:
ffi is a tidge slower for method call invocation. Also ffi can't use any "native C" code unless you combine it with compilation, for example with ffi-inliner.
ffi is much more cross-VM friendly.
rogerdpack
2010-09-08 20:06:11