[ODE] ODE .NET Bindings Performance Issues, Unsafe code, etc...

[Gonçalo Lopes]

Hi all,

I've been using the James Rayne's ODE.NET bindings for quite some time
and I was pretty excited to hear that some official bindings were
surging up in the main ODE development branch. This seemed like good
news mainly because Rayne's wrapper, although extremely efficient and
OOP clean, was still referencing ODE 0.5 and no additional progress
was done to complete or rewrite new versions of the wrapper.

However, upon closer examination of the official bindings I can't help
but have doubts about some of the design principles. I have had some
experience at writing wrappers to unmanaged code from scratch and I've
come to feel in the skin the pain of subtle decisions which can wholly
influence negatively the performance and usability of the library.

For instance, the Marshalling problem. It's really great that P/Invoke
and the Interop systems allow you to automatically declare an external
unmanaged function and have the Interop automatically take care of
things for you, but is it really worth it if each and every time you
call the function you have to copy a whole matrix and array instead of
a pointer? And if you're doing this in a middle of an iteration across
all your ODE world objects I'll guarantee you'll have a nice
performance bottleneck in your hands.

Rayne's bindings used Managed C++ to directly access the C-API and
exposing only .NET safe methods and types to the managed side and it
worked beautifully efficiency wise. Also it had a nice little class
structure on top of it, which is really the way you want to use ODE in
.NET, and not having IntPtr flying around. I'm not saying you can't do
the same from the C# side, just that you have to be more careful to
achieve the same level of functionality.

Basically, my objective is to probe around for the ultimate goals of
these official bindings, as some other list member said "it's some
heavy assumption / responsibility" to take. I'm also willing to extend
a concrete hand in code development and discussion of design criteria,
as I am already using ODE for some complex managed-level applications
and I would really appreciate some "definitive" wrapper.

To sum it up, and hopefully fire away a healthy discussion thread, I
think the .NET wrapper should have at least the following design
principles:

  * separate the wrapper into two design levels: API bindings level
(lower-level wrapper) and .NET level types and classes

  * 'unsafe' code should be allowed in the lower-level wrapper to
account for efficiency and 1:1 mapping (unsafe is not really unsafe...
I prefer the managed C++ pragma keyword for it: "unmanaged")

  * develop and expose a high-level OOP class hierarchy, following
standard .NET design procedures (and this one should be the one with
no 'unsafe' keywords in its usage)

  * prepare and approach a standardization of the unmanaged side ODE
C-API following object oriented patterns (what i mean is that some ODE
types can be wholly managed through API calls while others like dMass
have to be handled and managed by the user, even exposing its
structure definition). An ideal .NET binding should not even have to
worry about type definitions, but just passing pointers around and
using getter and setter functions to extract the members of a pointer.

I still have some other ideas up my alley but the post is already a
bit long and I want to have a feel for some of the opinions in the
community before I continue. I really want to keep ODE moving forwards
as it's a great library that could provide some tremendous potential
to open-source C# development if all this wrapper thing could be
definitely solved. I'm all for helping.

Keep up the good work,

Gonçalo