Android prepared-query performance compared with iOS

[udamaster]

We've been doing a lot of experimentation and building out some pretty interesting infrastructure on top of Ladybug 0.20.4 on the edge. However, we're seeing some performance issues on the Android side, and at this point, they're actually showstoppers.

I just wonder if anyone else has run into this and might have some additional insights. We will continue to dig in and see if we can figure it out. Been able to improve performance significantly, but it's actually still really poor.

Android uses the Java/JNI binding; iOS uses the native C API. Our tests use matching query logic, schemas and synthetic payloads. Hardware and some configuration settings differ, so this is not yet a fully controlled platform comparison.

We’ve used small, isolated tests to separate parameter construction, binding, query execution and transaction commit.

Two findings stand out:

• Replacing nested row-list parameters with flat column lists improved one Android write stage by roughly 25%, but did not resolve the broader gap.
• An already-packed count query still spent most of its measured native-call time inside the remaining C API/engine path. The JNI transition alone does not explain that result.

Mechanisms we’re investigating include:

• Extra copying of large list/string parameters.
• Value or query-plan cloning during prepared execution.
• Repeated allocation, binding and cleanup.
• Android-specific native execution, scheduling or build behavior.

These are suspects, not confirmed causes. We would appreciate guidance on parameter ownership, cloning and execution setup that could explain why comparable workloads perform much better on iOS.

Any insights appreciated!

[adsharma]

I pointed an agent at lbug_java.cpp. Here's what it says:

Standouts:

1. jstringToUtf8String does a Java round-trip for every jstring -> std::string: allocates a charset-name jstring,
   dispatches virtual String.getBytes(String) (which does Charset.forName("UTF-8") + exception path per call on ART),
   pins/copies byte[]. Called for every query (lbugConnectionQuery/Prepare), every bind key, every STRING param,
   struct field, arrow table name. Canonical fast path is GetStringUTFLength/GetStringUTFChars/ReleaseStringUTFChars —
   1 JNI call, zero Java objects.
2. utf8StringToJstring is the inverse tax on every std::string -> jstring: column names, STRING values,
   labels/property names, toString, errors. Canonical is NewStringUTF(). It also leaks 2 local refs per call (byteArr,
   charset jstring — no DeleteLocalRef).
3. Inconsistent with rest of file: lbugDatabaseInit* (:590), lbugNativeReloadLibrary (:568),
   UINT64/INT128/DECIMAL/UUID returns (:1933,1963,1978,2052) all correctly use GetStringUTFChars/NewStringUTF
   directly.

That explains iOS >> Android: iOS native bridge uses direct UTF-8 pointers; Android pays getBytes charset-lookup + 2
allocs + Java dispatch per string, per row/column.

A good way to get to the bottom of this is to run your workload and then use the perf tool to profile native code. If the problem is on the JVM side, then you'll want to use a different set of tools.