search

libgit2 / rugged

ruby bindings to libgit2
MIT License
2.25k stars 277 forks source link

Why isn't this in FFI? #12

Closed banister closed 13 years ago

banister commented 13 years ago

just curious, is there a reason it's not written with FFI? that would improve portability to other ruby implementations :)

brianmario commented 13 years ago

We'd discussed it and I raised my having bad experience performance-wise with FFI stuff in the past. Native bindings are almost always the best performing. The only ruby implementations I can think of that would be of concern currently are jRuby and IronRuby. jRuby is getting c-extension support soon (1.6?) so this might be less of an issue then. But, native java bindings is definitely be the better way to go for jRuby. I'm not even sure IronRuby has FFI support yet, but it may?

Maybe we (or someone who wants to contribute) could look at adding FFI bindings in addition to the C extension so we could fall back on platforms that need FFI. Any takers? :)

vmg commented 13 years ago

FFI is slow and mostly un-awesome. We aim to be fast and awesome. Have you seen the custom back-end support in the "decoupling" branch? That's the kind of awesome stuff that is unfeasible when wrapping over FFI.

JRuby is going to support C extensions natively very soon, and there are .NET bindings for libgit2 on the works which are already usable from IronRuby.

Rugged is already compatible with Rubinius, MRI (duh!) and REE... So there are really no plans to migrate to FFI at the moment. At least until I get an aneurysm.

Thanks for your concern, though! Is there any other Ruby platform you'd like to see Rugged working on?

banister commented 13 years ago

Nope. Thanks for your explanation, i had no idea FFI was so slow, so that's news to me :)

Cheers,

rkh commented 13 years ago

Note that native C extensions are far slower on Rubinius and JRuby than FFI extensions, due to a thing commonly known as synchronization hell (constantly coping all objects accessed from C level, since it doesn't know when some C ext decides to change the content).

brianmario commented 13 years ago

Right, on those platforms we get "handles" back instead of raw pointers like MRI/YARV. Given that, I'm personally not opposed to adding an FFI based driver in addition to the C extension so we can get the best of both worlds. I definitely wouldn't want to have to trade performance in MRI for jRuby/rbx if we could get it on both. I'm just not sure FFI stuff is on the immediate timeline given the rest of the API that need to be fleshed out in libgit2 itself (and here in rugged there after). I'd happily work with someone wanting to contribute some work to at least get it started though.