Performance evidence

PAM Mobile UI keeps gesture progress inside Android and sends PHP only semantic results. Benchmarks are separated by layer so a fast PHP encoder is not mistaken for smooth rendered frames.

Physical Android reference

The reference run used:

• Samsung Galaxy S23 Ultra (SM-S918B);
• Android API 36;
• debug instrumented build;
• July 24, 2026;
• 10,000-operation samples for most update paths; and
• explicit warm-up before measurement.

Operation	p50	p95	p99	Maximum
Decode/apply host update	18 µs	44 µs	53 µs	1,937 µs
Slider move and redraw	18 µs	21 µs	25 µs	58 µs
Calendar grid draw	1,269 µs	1,356 µs	1,403 µs	1,468 µs
DateTimePicker update	24 µs	28 µs	45 µs	2,206 µs
Accordion toggle	11 µs	17 µs	22 µs	1,796 µs
Checkbox toggle	3 µs	4 µs	4 µs	44 µs
RadioGroup selection	9 µs	13 µs	17 µs	103 µs
Create, update, release host	128 µs	154 µs	192 µs	1,946 µs

All 24 measured operation families stayed below their enforced p99 budget. A separate Samsung Galaxy S10 Android 12/API 31 run passed 39 functional instrumentation tests and the performance gates.

Semantic-event reduction

Ten thousand slider moves emitted zero per-move PHP callbacks and one final change event. That is a 10,000-to-1 reduction in bridge events compared with forwarding every sampled movement.

It is not evidence that PAM is 10,000 times faster than another framework.

Calendar drawing, DateTimePicker property changes, and several local state transitions also stay native. Components emit bounded semantic results rather than animation or pointer frames.

Run the instrumentation suite

../pam-native/android/gradlew \
  -p android \
  connectedDebugAndroidTest \
  -Pandroid.testInstrumentationRunnerArguments.class=dev.pam.mobileui.MobileUiHostPerformanceInstrumentedTest

Machine-readable output is logged under PamMobileUiBench.

Pending physical evidence

Implemented benchmark gates still awaiting a new physical-device reference include:

• sheet snapping and item activation;
• anchored collision-aware layouts and menu selection;
• compound-input focus and slot activation;
• semantic table layout;
• skeleton and persistent toast updates;
• image viewer navigation;
• Chat AI branches and prompt submission;
• file-tree expansion;
• rich MessageResponse parsing;
• unified scroll fling and property updates;
• image cold/warm/cache behavior;
• input latency and selection;
• responsive grid layout; and
• full-renderer list, memory, and frame profiles.

Static compilation is not reported as measured runtime evidence.

PHP composition benchmark

A reference host composed and encoded a realistic styled form tree 2,000 times per sample.

Metric	Result
Median total	996.910 ms
Median throughput	2,006.2 trees/s
Encoded frame	2,148 bytes
Peak PHP memory	8 MiB
PHP	8.4.23

Run:

composer benchmark

Claim boundary

Current results validate bounded host work and absence of per-frame PHP traffic on the measured devices.

They do not yet establish an end-to-end speedup over React Native, Nitro Modules, Flutter, or another framework. A comparative claim needs the same payload, physical device, release build, warm-up, sample count, frame statistics, memory method, and harness.

iOS implementation status

The iOS runtime uses CADisplayLink, requests up to 120 frames per second on iOS 15+, and commits queued native batches on the main thread. High-frequency scroll, dimensions, image-progress, input-selection, input-content-size, and pointer-move events are coalesced by identity before dispatch.

The renderer also keeps onEndReached calculation O(1) on the native scroll path and avoids creating onScroll payloads when only end-reached observation is enabled.

These are implementation properties, not benchmark results. No iPhone release-build frame-time, memory, startup, thermal, or energy reference has been published yet.