Index the backing slice in IValue::get_index instead of iter().nth() - #1630

Follow-up to RED-213492, split out of #1629.

Please read this first — it is not the fix the ticket asks for

The ticket hypothesis was that getAt(index) on packed typed arrays became linear, turning a per-element vector read into O(dim²). I measured it and that is not happening in the shipped module. Server-side usec_per_call on a release build of librejson.so, 65536-element packed f32 array:

Identical. Per-element cost across a full scan is flat too — 66ns/element at dim 1280, 92ns at 8192, 58ns at 65536 — so total cost is linear in elements read, not quadratic. The optimizer collapses the nth skip loop, because next() on the inner std::slice::Iter is a pointer bump and the discarded item construction is side-effect-free.

So: this PR does not speed up production, and the slow vector loads in the ticket are not caused by indexed-access complexity. That still needs a separate answer.

What this PR is for

arr.iter().nth(index) is O(index) by contract — ijson::array::ArrayIter implements only next(). Today it is fast because of an optimization we do not control, and that optimization already fails in another real build of this workspace. Same source, cargo test --release -p json_path, single read of the last element:

A full index-by-index scan there is genuinely quadratic. Whether that cliff shows up depends on inlining, so any future change to codegen settings, crate boundaries, or how get_index is reached could surface it in the module too.

The change

Index the backing slice directly via as_slice(): borrow the element for heterogeneous arrays, build the number for the 12 packed tags. Cost is index-independent by construction instead of by optimizer behaviour.

Measured after the change:

• the slow build above: 17.74ns for the last element at n=65536 (was 966,498ns)
• the shipped module: unchanged within noise — scan of 1280 elements 84.93µs before, 85.62µs after; GETAT 8.59µs → 8.38/8.74µs

Same get_index also backs JSONPath index/slice evaluation and JSON.ARRINDEX, so those get the same guarantee.

Tests

• json_node.rs: indexing over all 12 packed array tags; heterogeneous arrays return a borrow rather than a clone (asserted by pointer identity); out-of-bounds and non-array cases; and a guard that per-element cost does not grow with array length (512 vs 8192 elements, best-of-5 passes, asserts under 4x where linear would be ~16x). That guard fails on the previous implementation in this build.
• c_api.rs: JSONAPI_getAt over every packed array tag, covering the LLAPI entry point RediSearch uses.

cargo test -p json_path (299 tests) and -p redis_json green; cargo clippy --all-targets clean on both crates.

Reviewer judgement needed

1. Is a no-op-in-production change worth taking? The argument is robustness, not speed. If you would rather not carry a timing-sensitive test for a cliff that is currently latent, closing this is a reasonable call.
2. The timing guard. It is best-of-5 with a 4x threshold against an expected 16x, so it has headroom, but it is still wall-clock in a unit test and CI runners are noisy. Happy to drop it and keep only the deterministic per-type tests.
3. half is added as a dev-dependency of json_path (Cargo.toml + Cargo.lock) so the tests can construct f16/bf16 arrays.

Generated by Claude Code