⚡️ Speed up method ExpectCallTransformer.transform by 173% in PR #1523 (feat/js-dot-call-instrumentation)#1527
Conversation
The optimized code achieves a **172% speedup** (85.2ms → 31.3ms) by eliminating a critical O(n²) performance bottleneck in the `transform()` method. ## Key Optimization **Problem**: The original code called `is_inside_string(code, match.start())` for every regex match found. This function scans from position 0 to the match position each time, resulting in O(n²) complexity when processing code with many matches. **Solution**: The optimization replaces these repeated scans with **incremental string state tracking** directly in the main loop. Instead of rescanning from the beginning for each match, the code maintains `in_string`, `string_char`, and `last_checked_pos` variables that preserve state between iterations. When a new match is found, only the code between `last_checked_pos` and `match_start` is scanned to update the string state. ## Performance Impact The line profiler data clearly shows the improvement: - **Original**: `is_inside_string()` consumed 0.618s (95.2% of transform time) with 432 calls scanning 887,510 characters total - **Optimized**: The inline tracking logic in transform() consumes only 0.021s (33% of transform time) by scanning just 28,273 characters incrementally Test results demonstrate strong gains on workloads with many matches: - `test_transform_many_invocations`: 12.3ms → 4.84ms (155% faster) - `test_transform_large_code_file`: 40.6ms → 14.0ms (191% faster) - `test_transform_alternating_patterns`: 2.64ms → 519μs (408% faster) - `test_transform_mixed_qualified_names`: 14.0ms → 5.14ms (173% faster) The optimization particularly benefits code with frequent expect() calls, as each avoided `is_inside_string()` call saves scanning hundreds or thousands of characters. This makes the transformer significantly faster on realistic test files with multiple assertions.
PR Review SummaryPrek Checks✅ All checks passed — ruff check and ruff format both passed with no issues. Mypy✅ No new type errors introduced by this PR. The only mypy errors are pre-existing issues (missing return type annotations in test methods, missing library stubs for Code Review✅ No critical issues found. This PR optimizes
The incremental tracking logic correctly mirrors the original Test Coverage
Last updated: 2026-02-18 |
4c441c9
into
feat/js-dot-call-instrumentation
⚡️ This pull request contains optimizations for PR #1523
If you approve this dependent PR, these changes will be merged into the original PR branch
feat/js-dot-call-instrumentation.📄 173% (1.73x) speedup for
ExpectCallTransformer.transformincodeflash/languages/javascript/instrument.py⏱️ Runtime :
85.2 milliseconds→31.3 milliseconds(best of65runs)📝 Explanation and details
The optimized code achieves a 172% speedup (85.2ms → 31.3ms) by eliminating a critical O(n²) performance bottleneck in the
transform()method.Key Optimization
Problem: The original code called
is_inside_string(code, match.start())for every regex match found. This function scans from position 0 to the match position each time, resulting in O(n²) complexity when processing code with many matches.Solution: The optimization replaces these repeated scans with incremental string state tracking directly in the main loop. Instead of rescanning from the beginning for each match, the code maintains
in_string,string_char, andlast_checked_posvariables that preserve state between iterations. When a new match is found, only the code betweenlast_checked_posandmatch_startis scanned to update the string state.Performance Impact
The line profiler data clearly shows the improvement:
is_inside_string()consumed 0.618s (95.2% of transform time) with 432 calls scanning 887,510 characters totalTest results demonstrate strong gains on workloads with many matches:
test_transform_many_invocations: 12.3ms → 4.84ms (155% faster)test_transform_large_code_file: 40.6ms → 14.0ms (191% faster)test_transform_alternating_patterns: 2.64ms → 519μs (408% faster)test_transform_mixed_qualified_names: 14.0ms → 5.14ms (173% faster)The optimization particularly benefits code with frequent expect() calls, as each avoided
is_inside_string()call saves scanning hundreds or thousands of characters. This makes the transformer significantly faster on realistic test files with multiple assertions.✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr1523-2026-02-18T13.29.34and push.