Generate direct string lengths and unit-step slices

[Alek99]

String Var lengths and ordinary slices currently split the entire string into an array first. Generate direct .length and .slice(start, stop) calls for omitted or constant integer unit steps, avoiding whole-string array allocation. Preserve current UTF-16 code-unit behavior and source/boundary Var metadata; other steps keep the existing array path.

Validation:

• Four generated-expression regression cases failed on the unchanged base.
• Full unit suite: 8,305 passed, 18 skipped; 75.95% coverage.
• Tests execute the generated JavaScript against empty strings, non-BMP/combining characters, lone surrogates, negative/out-of-range dynamic bounds, and omitted/unit steps.
• Source and boundary hooks/imports are checked independently; existing stepped-slice behavior remains covered.
• Added three CodSpeed Python expression-generation benchmarks. These do not measure browser rendering.
• Repository-wide Ruff lint/format and pyright reflex tests passed.

No new public API. Based directly on main, independent of the other performance changes.

[greptile-apps]

Greptile Summary

This PR optimizes generated JavaScript for StringVar length and ordinary slicing while preserving UTF-16 semantics and Var metadata.

• Generates direct .length expressions instead of splitting strings into arrays.
• Generates direct .slice(start, stop) calls for omitted and Python-integer unit steps.
• Retains the existing array implementation for stepped slices.
• Adds expression-generation benchmarks and JavaScript semantic regression coverage.
• The optimization currently misses statically known unit steps represented as literal NumberVars.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking gap where literal NumberVar unit steps miss the intended optimization.

Direct string length and slicing preserve existing semantics and metadata, while the sole accepted issue is limited to avoidable allocation for a supported statically known step representation.

Files Needing Attention: packages/reflex-base/src/reflex_base/vars/sequence.py; tests/units/reflex_base/vars/test_sequence.py

Important Files Changed

Filename	Overview
packages/reflex-base/src/reflex_base/vars/sequence.py	Adds direct string length and unit-slice operations with correct metadata and UTF-16 behavior, but does not recognize literal NumberVar steps equal to one.
tests/units/reflex_base/vars/test_sequence.py	Adds strong metadata, fallback-path, and JavaScript semantic coverage, but omits the supported literal-NumberVar unit-step case.
tests/benchmarks/test_string_operations.py	Adds focused CodSpeed benchmarks for Python-side generation of string length and direct slice expressions.
tests/units/test_var.py	Updates established expression assertions to the new direct JavaScript operations.
packages/reflex-base/news/+direct-string-operations.performance.md	Concisely documents the downstream string-operation performance improvement.

_{Reviews (1): Last reviewed commit: "perf: generate direct string lengths and..." | Re-trigger Greptile}

[greptile-apps]

Literal Unit Steps Missed

A unit step represented as a constant LiteralNumberVar, such as LiteralNumberVar.create(1), is supported by the existing slice machinery but fails the isinstance(i.step, int) check. It therefore still generates the allocation-heavy split("").slice(...).join("") path, leaving the intended constant-unit-step optimization incomplete. Recognize integer literal Vars whose value is 1 and add a regression case alongside the Python int case.

[codspeed-hq]

Merging this PR will not alter performance

✅ 32 untouched benchmarks
🆕 3 new benchmarks
⏩ 8 skipped benchmarks¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
🆕	test_string_operation_codegen[length]	N/A	229.2 µs	N/A
🆕	test_string_operation_codegen[slice]	N/A	289.3 µs	N/A
🆕	test_string_operation_codegen[unit_slice]	N/A	291.2 µs	N/A

---

_{Comparing codex/perf-direct-string-operations (637cdb4) with main (c49a85d)}

Footnotes

1. 8 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩