Question: Can we use php ffi to access rust libs?

[aszenz]

Description

Description

Since php 7.4 , we have the ffi extension which allows for interoperability with dynamic c libs, so there is less need to install extensions.

Rust libs can be packaged as dynamic c libs using cbindgen, so my question is can this lib also support packaging rust libs as PHP FFI pkgs.

A PHP FFI pkg needs two things:

• C ABI compatible dynamic lib .so/.dll
• PHP boilerplate for converting datatypes

Examples of PHP FFI pkgs:

• https://github.com/satur-io/duckdb-php

Examples of such rust libs are

• PyO3 for python
• JNI for Java

Repository

No response

I have already tried

• Searching the documentation and guide
• Searching existing issues

[Xenira]

Hey @aszenz, haven't looked into that yet, but sounds really interesting. Thank you for bringing this up.

Will do some research and try some stuff.

[ptondereau]

Hey! Just adding some thoughts here:

• Crossing FFI has a cost for the performance no matter the language you're using.
• I suggest looking at WASM implementation or just using our tools here 😅.

[aszenz]

Hey! Just adding some thoughts here:

• Crossing FFI has a cost for the performance no matter the language you're using.
• I suggest looking at WASM implementation or just using our tools here 😅.

Yes FFI has a cost, but my understanding of benchmarks in https://github.com/satur-io/duckdb-php, it wasn't significant compared to php extension.

FFI pkgs are easier to distribute via composer, (simply include the lib files for each platform), while extensions remain hard to install.

[dhernandez]

My two cents after working building an FFI-based package for a while:

• FFI overhead is negligible in some cases (but not sure at all this extends to ALL cases).
• Converting data types is actually the nightmare when you try to work with external types. This applies to both FFI and standard C extensions or those written in Rust.
• Installing an FFI-based package seems to be quite easier than dealing with PHP native extensions. Maybe PIE change this in the future, but making the library available just by a simple composer require command has no competitor nowadays.
• The development and maintenance for a FFI-based package and a native extension has no comparison. This affects the entire development cycle, from starting with something simple to release to production and including testing, debugging, etc. FFI has a much smaller adaptation curve, which means that it can also facilitate the incorporation of contributors.

Especially because of the last two points I decided to focus my efforts in a FFI-based package instead of in a native extension.

To be honest I would like to see really fair benchmarks comparing FFI over PHP native extensions. I would say using native extension will not give a big improvement in switching context and data type transformation, the most important and costly processes related to performance, but it's just speculation.