CRT Binding Performance — Flamegraph Index

Native C implementation with zero FFI overhead. The tiny event-delivery slice (0.04 %) is purely memory management (aws_s3_request_release), not marshalling. Serves as the performance ceiling for all other bindings.

FFI overhead jumps 169× versus C. Nearly all event-delivery time (99.4 %) is PyBytes_FromStringAndSize — allocating Python bytes objects and copying each C buffer into Python-managed memory. GIL contention and reference counting add further pressure.

FFI overhead jumps 308× versus C. The binding creates a Java byte array (byte[]) for each C buffer, copying data across the JNI boundary into JVM-managed heap memory. JNI call overhead and GC tracking compound the cost; 99.6 % of event-delivery time is pure marshalling. Note: switching to DirectByteBuffer (zero-copy, analogous to Python's memoryview) brings Java throughput back to C levels.

Java binding updated to return a DirectByteBuffer that wraps the C-owned buffer directly — no heap copy across the JNI boundary. Throughput jumps from 15.7 Gb/s to 65.0 Gb/s (4.1× improvement), nearly matching the native C baseline. The residual gap (~7 %) is attributable to JNI framing and JVM object creation, not data copying.

Python binding updated to expose a memoryview into the C-owned buffer instead of copying into a bytes object. Throughput jumps from 33.5 Gb/s to 60.6 Gb/s (1.8× improvement). The remaining gap vs C is primarily GIL acquisition and CPython interpreter overhead — not data copying. Caveat: memoryview is zero-copy only while the caller holds the view; any downstream processing that materialises the data into Python objects will reintroduce the copy.

C writing to disk — sets the disk-I/O bound baseline. No application callback invoked; all throughput comes from the CRT's internal write path.

Python writing to disk achieves 93 % of C performance — a dramatic contrast to the 48 % seen in the RAM-download test. The 7 % gap is attributable to Python interpreter startup cost and minor scheduling overhead, not data marshalling.

Java writing to disk matches C throughput exactly. In the RAM-download test Java reached only 23 % of C — meaning 77 % of Java's overhead is purely FFI marshalling, eliminated the moment no callback crosses the language boundary.

Profiles of 3rd-party AWS SDK clients backed by CRT on a 10,000 × 1 MiB S3 download workload. Includes system-level perf flamegraphs and Python-level py-spy profiles. The Java SDK CRT client achieves 22.88 Gb/s; the Python free-threading variant reaches 5.18 Gb/s.