⚡️ Speed up method StandaloneCallTransformer._parse_bracket_standalone_call by 147% in PR #1523 (feat/js-dot-call-instrumentation)

[codeflash-ai]

⚡️ 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.

This PR will be automatically closed if the original PR is merged.

---

📄 147% (1.47x) speedup for StandaloneCallTransformer._parse_bracket_standalone_call in codeflash/languages/javascript/instrument.py

⏱️ Runtime : 1.72 milliseconds → 697 microseconds (best of 144 runs)

📝 Explanation and details

The optimized code achieves a 147% speedup (2.47x faster) by fundamentally changing how the _find_balanced_parens method searches through JavaScript code to find matching parentheses.

Key Optimization: Regex-Based Scanning

The original code iterates through every single character in the string (20,283 iterations) to find quotes and parentheses. The optimized version uses a precompiled regex pattern (self._special_re = re.compile(r'["\'()]')`) to jump directly between special characters, reducing iterations from 20,283 to just 1,268 - a 94% reduction in loop iterations.

Why This Is Faster

1. Compiled regex scanning: The regex engine (implemented in C) can skip over irrelevant characters much faster than Python's character-by-character iteration
2. Fewer comparisons: Instead of checking if char in quotes on every character, the regex only returns when it finds a relevant character
3. Reduced overhead: The optimized loop executes 16x fewer times, eliminating 19,000+ Python bytecode interpretation cycles

Line Profiler Evidence

The _find_balanced_parens function shows dramatic improvement:

• Original: 18.4ms total (20,321 loop iterations @ 182.7ns per hit on the while condition)
• Optimized: 3.2ms total (1,305 loop iterations @ 194.2ns per hit)
• 5.7x faster for this function alone

The while loop body itself drops from consuming 98.3% of function time (checking every character) to the regex search consuming just 22.7% (jumping between special characters).

Trade-offs

The regex approach adds small overhead for each match.group() and match.start() call (9.3% + 7.5% of optimized time), but this is vastly outweighed by eliminating 19,000 character checks.

Impact

Since _parse_bracket_standalone_call spends 98.6% of its time in _find_balanced_parens, this optimization cascades up the call stack. This makes the code particularly beneficial when parsing JavaScript files with deeply nested function calls or large argument lists where the parenthesis-matching logic is heavily exercised.

✅ Correctness verification report:

Test	Status
⚙️ Existing Unit Tests	🔘 None Found
🌀 Generated Regression Tests	✅ 64 Passed
⏪ Replay Tests	🔘 None Found
🔎 Concolic Coverage Tests	🔘 None Found
📊 Tests Coverage	100.0%

🌀 Click to see Generated Regression Tests

To edit these changes git checkout codeflash/optimize-pr1523-2026-02-18T13.11.30 and push.

[claude]

PR Review Summary

Prek Checks

✅ All checks pass (ruff check and ruff format). No issues found.

Mypy

⚠️ Pre-existing import-untyped error for codeflash.code_utils.code_position — not introduced by this PR.

Code Review

The optimization replaces character-by-character scanning in _find_balanced_parens with regex-based scanning using a precompiled pattern re.compile(r'["'"'()]')`. This skips non-special characters in C rather than iterating in Python.

No critical issues found. The optimization is behaviorally equivalent to the original:

• String literal handling (quote detection, escape checking) is preserved
• Parenthesis depth tracking logic is unchanged
• Edge cases (no match found, unbalanced parens) correctly return (None, -1)
• The in_string guard correctly prevents parens inside string literals from affecting depth

Test Coverage

File	Stmts	Miss	Coverage
codeflash/languages/javascript/instrument.py	752	186	75%
Overall	48,826	10,396	79%

Changed lines analysis:

• Lines 182-184 (_special_re initialization): ✅ Covered
• Lines 386-416 (_find_balanced_parens body): ✅ Mostly covered (23/25 statements)
• Line 391 (return None, -1 — no regex match): ❌ Not covered (error path)
• Line 414 (return None, -1 — unbalanced depth): ❌ Not covered (error path)

The two uncovered lines are edge-case error-handling returns (malformed input). The core optimization logic is fully exercised by tests.

Overall: No coverage regression. File meets the 75% threshold.

---

Last updated: 2026-02-18

[KRRT7]

Closing stale bot PR.