Performance implications of a Swift program calling a Rust library compiled as a dylib?

Question

I am writing a OS X application in Swift and considering implementing a portion of my model code (MVC pov) in Rust in order to gain portability of usage on a web server (since Swift doesn't extend into the web server space).

If I compile my Rust code as a dynamic library (.dylib) and follow certain guidelines, I understand that it will produce an external interface that will look like a typical "C" interface that Swift can then consume.

What would the performance implications be of Swift communicating with the dylib in this instance? Would they be any different to communicating with something written in C? The model component in the dylib can be assumed to be central to the application and hence the communication is anticipated to be "chatty".

[If I were to code the whole thing in Swift, the model portion would have been contained in a separate framework/library which is very similar to a dylib in any event.]

Answer 1

When using a Foreign Function Interface, I can see two major cost centers (performance-wise):

1. Conversion: if you need to convert the data back and forth (either on one side or even worse on both sides)
2. Lost optimization opportunity: no inlining, and thus lots of missed opportunities

The latter can be recovered with a "better" toolchain, especially since in this case both languages compile down to LLVM IR, and I know it is an ambition for at least some Rust developers/users to manage this for Rust/C interaction, but I have never seen it yet.

The former requires a careful design and even then it can be inevitable that some conversions will occur if you wish to use native compound types on either side ( String being a prime candidate).