You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bindings: fewer JPype crossings on a short read (one nextRows call, scalar parameters without the conversion walk) #213
Found by the levers audit of the October benchmark gaps: a Python read through the bindings costs one JPype crossing (3 to 4 microseconds) per call, about a fifth of a one-row read, and two of them are avoidable. to_list() made a second nextRows call only to see an empty batch and then close() crossed once more; and plain scalar parameters (int, float, str, bool, None) walked the general conversion path before being boxed.
Measured on the benchmark's own read shapes on the official 26.10.1 jars (interleaved, 13 runs per arm, laptop, ratios only): a documents SELECT by key through to_list() 0.83x [0.80, 0.89], p=0.0003; Database._java_parameters for a one-key dict 0.79x and for three positional values 0.78x (p<0.0001). A whole new-order or payment transaction shows no detectable effect, so this is a small, safe win, not a headline.
Two commits, with tests that fail on the old code (4 of 9 new result-set tests, the scalar-parameter spy test). It lands on main after the 26.10.1 release is pushed, so the release stays the reviewed commit; the re-pin wheel picks it up through main.
Activity
bindings: fewer JPype crossings on a short read (one nextRows call, s…