On Thu, Mar 4, 2010 at 9:27 AM, Thomas E Enebo <tom.en...@gmail.com> wrote:
> The main downside of Jacob for me was that it seemed to run incredibly
> slowly in comparison to MRI (from what I remember at least an order of
> magnitude slower). I did implement a simple win32ole shim using JI
> layer (which obviously slows it down more), but it seemed like the
> library must be doing something that MRI's extension isn't on every
> call. Still I suppose something which works is better than nothing at
> all. Who knows, Jacob may have fixed the speed issue since
> then....OR....I was using Jacob wrong?
I'd say if Brian has a mostly-complete version based on Jacob, we
should try testing it out and see how the performance looks. If it's
no longer a problem, then we have a completed library we could start
providing today.
Regarding FFI...
> I still like the idea of an FFI version. It might need to screw with
> 32 + 64 bit bindings for some APIs (maybe?), but it in theory, it
> could become the implementation for MRI and JRuby (assuming it worked
> well and MRI decided not to maintain their 3000 lines of C code --
> which is true for 1.9 already right?). Since windows is supposed to
> be binary compatible across versions I think that FFI is in a sweet
> spot there, so I don't expect many/any struct binding layout issues.
This is actually a pretty compelling reason to do it in FFI, even if
it takes longer to do an FFI version. Having all FFI-supporting impls
using the same win32ole code would be outstanding. So perhaps we go
with Brian's "almost done" version for now and those of you interested
in implementing an FFI version should still proceed with your efforts?
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
