Skip to content

Conversation

@viirya
Copy link
Member

@viirya viirya commented Dec 29, 2025

Which issue does this PR close?

  • Closes #.

Rationale for this change

What changes are included in this PR?

Replace .chars().skip().collect::<String>() with zero-copy string slicing using char_indices() to find the byte offset, then slice with &value[byte_offset..].

This eliminates unnecessary String allocation per row when a start position is specified.

Changes:

  • Use char_indices().nth() to find byte offset for start position (1-based)
  • Use string slicing &value[byte_offset..] instead of collecting chars
  • Added benchmark to measure performance improvements

Optimization:

  • Before: Allocated new String via .collect() for each row with start position
  • After: Uses zero-copy string slice

Benchmark results:

  • size=1024, str_len=32: 96.361 µs -> 41.458 µs (57.0% faster, 2.3x speedup)
  • size=1024, str_len=128: 210.16 µs -> 56.064 µs (73.3% faster, 3.7x speedup)
  • size=4096, str_len=32: 376.90 µs -> 162.98 µs (56.8% faster, 2.3x speedup)
  • size=4096, str_len=128: 855.68 µs -> 263.61 µs (69.2% faster, 3.2x speedup)

The optimization shows greater improvements for longer strings (up to 73% faster) since string slicing is O(1) regardless of length, while the previous approach had allocation costs that grew with string length.

Are these changes tested?

Are there any user-facing changes?

@github-actions github-actions bot added the functions Changes to functions implementation label Dec 29, 2025
…ition is provided

Replace `.chars().skip().collect::<String>()` with zero-copy string slicing
using `char_indices()` to find the byte offset, then slice with `&value[byte_offset..]`.

This eliminates unnecessary String allocation per row when a start position
is specified.

Changes:
- Use char_indices().nth() to find byte offset for start position (1-based)
- Use string slicing &value[byte_offset..] instead of collecting chars
- Added benchmark to measure performance improvements

Optimization:
- Before: Allocated new String via .collect() for each row with start position
- After: Uses zero-copy string slice

Benchmark results:
- size=1024, str_len=32:  96.361 µs -> 41.458 µs (57.0% faster, 2.3x speedup)
- size=1024, str_len=128: 210.16 µs -> 56.064 µs (73.3% faster, 3.7x speedup)
- size=4096, str_len=32:  376.90 µs -> 162.98 µs (56.8% faster, 2.3x speedup)
- size=4096, str_len=128: 855.68 µs -> 263.61 µs (69.2% faster, 3.2x speedup)

The optimization shows greater improvements for longer strings (up to 73% faster)
since string slicing is O(1) regardless of length, while the previous approach
had allocation costs that grew with string length.
@viirya viirya force-pushed the regexp_count_optimize branch from 8f465d6 to dbdc19c Compare December 29, 2025 19:43
@viirya viirya requested a review from andygrove December 30, 2025 00:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

functions Changes to functions implementation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant