[objective_c] FFI is slower than method channels in some cases

[HosamHasanRamadan]

I am building a package to get IANA timezone ID and list of supported timezones using native binding.
And comparing my package to other package that uses method channels it seems slower in some situations

https://pub.dev/packages/system_timezone
https://pub.dev/packages/flutter_timezone

Speed numbers in μs

Here are some benchmarks on MacOS App in release mode:

Get current time zone ID

run number	r1	r2	r3	r4	r5	r6
FFI	748	21	9	14	7	4
Method Channel	448	86	100	279	66	64

I ran the benchmark multiple times, what I have observed:

• FFI first run is way worse than next runs
• FFI first run could be worse than method Channel

Get list of supported timezones

run number	r1	r2	r3	r4	r5	r6
FFI	5234	1371	1256	1117	869	916
Method Channel	579	308	4626	320	269	261

I ran the benchmark multiple, what I have observed:

• FFI is consistency way worse than method channels
• FFI first run is way worse than next runs
• Converting NSArray to List<String> is the cause of slowness

After the benchmarks :
1- Is there a way to speed up first run ?
2- Is there more efficient way to convert NSArray to List<String> ?

Benchmark repo:
https://github.com/HosamHasanRamadan/native-vs-method-channel

Flutter doctor

[✓] Flutter (Channel stable, 3.22.3, on macOS 14.3.1 23D60 darwin-arm64, locale en-EG)

• Flutter version 3.22.3 on channel stable at /Users/hosamhasan/fvm/versions/stable

• Upstream repository https://github.com/flutter/flutter.git

• Framework revision b0850beeb2 (7 days ago), 2024-07-16 21:43:41 -0700

• Engine revision 235db911ba

• Dart version 3.4.4

• DevTools version 2.34.3

  

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)

• Android SDK at /Users/hosamhasan/Library/Android/sdk

• Platform android-34, build-tools 34.0.0

• ANDROID_HOME = /Users/hosamhasan/Library/Android/sdk

• Java binary at: /Users/hosamhasan/Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java

• Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

• All Android licenses accepted.

  

[✓] Xcode - develop for iOS and macOS (Xcode 15.2)

• Xcode at /Applications/Xcode-15.2.0.app/Contents/Developer

• Build 15C500b

• CocoaPods version 1.15.2

  

[✓] Chrome - develop for the web

• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

  

[✓] Android Studio (version 2023.1)

• Android Studio at /Users/hosamhasan/Applications/Android Studio.app/Contents

• Flutter plugin can be installed from:

🔨 https://plugins.jetbrains.com/plugin/9212-flutter

• Dart plugin can be installed from:

🔨 https://plugins.jetbrains.com/plugin/6351-dart

• Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

  

[✓] IntelliJ IDEA Community Edition (version 2023.3.2)

• IntelliJ at /Users/hosamhasan/Applications/IntelliJ IDEA Community Edition.app

• Flutter plugin can be installed from:

🔨 https://plugins.jetbrains.com/plugin/9212-flutter

• Dart plugin version 233.14888

  

[✓] VS Code (version 1.91.1)

• VS Code at /Applications/Visual Studio Code.app/Contents

• Flutter extension version 3.93.20240702

  

[✓] Connected device (3 available)

• macOS (desktop) • macos • darwin-arm64 • macOS 14.3.1 23D60 darwin-arm64

• Mac Designed for iPad (desktop) • mac-designed-for-ipad • darwin • macOS 14.3.1 23D60 darwin-arm64

• Chrome (web) • chrome • web-javascript • Google Chrome 126.0.6478.183

  

[✓] Network resources

• All expected network resources are available.

  

• No issues found!

[liamappelbe]

1- Is there a way to speed up first run ?

I wouldn't worry too much about that. I assume you're running these benchmarks in JIT mode? All Dart JIT programs get faster as you run them.

You'll probably see some initial slowness even in AOT. There's some initialization logic that happens the first time you use a class or method (eg looking up symbols in the dylib, loading the class etc).

The first benchmark is dominated by these sorts of issues. But you said those times are all in μs, so I don't think this will be noticable to users.

2- Is there more efficient way to convert NSArray to List<String> ?

Not at the moment. I would like to improve NSArray's bindings so that you can use it like an ordinary List. Then you won't actually need to convert it. Something like package:jni's JArray.