Introducing a C api?

[leo-collins]

We are considering moving to rstar from our current solution (libspatialindex) for performance improvements. However we would need to implement a C api to interface rstar from our code. From a quick google it seems the best approach would be a separate crate e.g. rstar-capi containing the bindings so we could keep rstar safe (this is what e.g. https://github.com/rust-lang/regex do).

Is this something the maintainers are interested in? I would be happy to give this a go and make a PR if so.

[adamreichold]

If you are willing to do the work, I think it does make sense to have this crate here in the code base as it would be much easier to coordinate changes and ensure that the C wrapper stays in sync with the Rust code.

One thing that I wonder though is whether we really bring algorithmic improvements over libspatialindex to the table? If there are improvements to be had, I wonder if they actually come from small technical efficiencies due to Rust being a more modern language (generics, visibility, etc.) than C and hence might be lost in the C API translation?

[leo-collins]

I'm told that a lot of the overhead in libspatialindex is coming from the need to support file-backed indices. In our tests rstar is around an order of magnitude faster than libspatialindex for querying. I would be surprised if a C api added enough overhead to cancel that.

If you're happy to have the C api in this repo I'll go ahead and open a PR.

[urschrei]

I'll echo Adam's sentiments here. I'm surprised (I gather that tuning Buffer for your use case is key for speed when using the disk-backed indexes) but confess I haven't had much interaction with it directly. I'd certainly be interested in a comparison, but let's take it one step at a time.