The new-ish DEFINE_FFI_NATIVE_ENTRY way of binding C++ -> Dart can be much more performant than DEFINE_NATIVE_ENTRY (see the linked CLs). However, bots fail since the simulated environments also need to support FFI and only arm64 supports FFI native entries so far.
This issue is meant to track the progress on this. Once FFI_NATIVE_ENTRY is supported we can land the following:
In general, it looks like all native implementations that don't need interaction with the Dart API could be migrated to use FFI_NATIVE_ENTRY for an easy performance boost.
cc @mraleph
The new-ish
DEFINE_FFI_NATIVE_ENTRYway of binding C++ -> Dart can be much more performant thanDEFINE_NATIVE_ENTRY(see the linked CLs). However, bots fail since the simulated environments also need to support FFI and only arm64 supports FFI native entries so far.This issue is meant to track the progress on this. Once FFI_NATIVE_ENTRY is supported we can land the following:
In general, it looks like all native implementations that don't need interaction with the Dart API could be migrated to use FFI_NATIVE_ENTRY for an easy performance boost.
cc @mraleph