⚡️ Speed up function detect_optimization_opportunities by 36% in PR #1561 (add/support_react)#1562
Conversation
The optimized code achieves a **35% runtime improvement** (8.09ms → 5.95ms) through strategic regex avoidance and elimination of expensive string operations:
## Key Optimizations
1. **Eliminated Component Source Join**: Removed `component_source = "\n".join(component_lines)` which was creating a large concatenated string. This alone saves significant memory allocation and copying overhead, especially for large components (tests show 43-62% speedup on 1000+ line components).
2. **Fast-Path Substring Checks Before Regex**: Added cheap substring presence checks before running expensive regex patterns:
- `if "={" not in line: continue` before JSX prop regexes (reduces ~2,664 regex calls in typical cases)
- `if "." not in stripped: continue` before expensive operations regex (reduces ~2,523 regex calls)
- `if ("const" not in stripped and "let" not in stripped...)` before function definition regex (reduces ~1,414 regex calls)
3. **Line-by-Line useCallback Detection**: Changed from `USECALLBACK_RE.search(component_source)` on the entire joined string to iterating lines with substring check first (`if "useCallback" in l`), then regex only when needed. This avoids regex on large text and short-circuits on first match.
## Performance Impact by Workload
The optimization particularly benefits:
- **Large components** (1000+ lines): 26-43% faster, as seen in `test_large_scale_detection_performance` and `test_detection_accuracy_with_1000_items`
- **Dense JSX with many props** (100+ inline props): 54-62% faster, as shown in `test_many_inline_props_in_large_component` and `test_complex_nested_jsx_structure`
- **Components with many function definitions**: 27% faster in `test_many_function_definitions`
The approach maintains identical detection logic and results while dramatically reducing computational cost through algorithmic improvements: O(n) substring checks filter out non-matching lines before expensive O(n*m) regex operations.
PR Review SummaryPrek ChecksAll checks passing. Fixed 10 linting issues in commit
Mypy: 26 pre-existing errors in Code ReviewThe optimization to
Minor observations (non-blocking):
No critical bugs, security issues, or breaking changes found. Test Coverage
Note: Most new React framework files ( Overall: 2411 passed, 8 failed (all in Last updated: 2026-02-20 |
The optimized code achieves a **149% speedup** (539μs → 216μs) by replacing recursive tree traversal with an iterative stack-based approach. ## Key Optimization **Eliminated recursive function calls**: The original implementation used `any(_contains_jsx(child) for child in node.children)`, which created a new stack frame for each recursive call. The line profiler shows this consumed **84.1% of total runtime** (2.23ms out of 2.65ms). The optimized version uses an explicit stack data structure with a while loop, avoiding Python's function call overhead entirely. ## Why This Is Faster 1. **No recursive overhead**: Each recursive call in Python involves creating a new stack frame, copying arguments, and managing return values. The iterative approach eliminates all of this. 2. **Early termination efficiency**: Both versions can return `True` early when JSX is found, but the iterative version does this more efficiently without unwinding the call stack. 3. **Better memory locality**: The explicit stack keeps all traversal state in a single list object, improving CPU cache utilization compared to scattered stack frames. ## Performance Characteristics The optimization shines particularly well on: - **Deep nesting**: 100-level deep tree shows **691% speedup** (94.9μs → 12.0μs) - **Wide trees with JSX at end**: 100 siblings with JSX as last child shows **1985% speedup** (34.3μs → 1.64μs) - **Balanced trees**: 512-node tree shows **195% speedup** (308μs → 104μs) Trade-off: Direct JSX matches (root node is JSX) are ~20-26% slower due to stack initialization overhead, but these simple cases are already extremely fast (<1μs) and the optimization dramatically benefits complex real-world AST traversals. ## Impact For React code analysis tools that traverse Abstract Syntax Trees to detect JSX elements, this optimization significantly reduces profiling overhead, especially when analyzing large component files with deeply nested or wide component trees.
⚡️ Codeflash found optimizations for this PR📄 149% (1.49x) speedup for
|
…2026-02-20T03.28.04 ⚡️ Speed up function `_contains_jsx` by 149% in PR #1562 (`codeflash/optimize-pr1561-2026-02-20T03.10.31`)
|
This PR is now faster! 🚀 @claude[bot] accepted my optimizations from: |
⚡️ This pull request contains optimizations for PR #1561
If you approve this dependent PR, these changes will be merged into the original PR branch
add/support_react.📄 36% (0.36x) speedup for
detect_optimization_opportunitiesincodeflash/languages/javascript/frameworks/react/analyzer.py⏱️ Runtime :
8.09 milliseconds→5.95 milliseconds(best of250runs)📝 Explanation and details
The optimized code achieves a 35% runtime improvement (8.09ms → 5.95ms) through strategic regex avoidance and elimination of expensive string operations:
Key Optimizations
Eliminated Component Source Join: Removed
component_source = "\n".join(component_lines)which was creating a large concatenated string. This alone saves significant memory allocation and copying overhead, especially for large components (tests show 43-62% speedup on 1000+ line components).Fast-Path Substring Checks Before Regex: Added cheap substring presence checks before running expensive regex patterns:
if "={" not in line: continuebefore JSX prop regexes (reduces ~2,664 regex calls in typical cases)if "." not in stripped: continuebefore expensive operations regex (reduces ~2,523 regex calls)if ("const" not in stripped and "let" not in stripped...)before function definition regex (reduces ~1,414 regex calls)Line-by-Line useCallback Detection: Changed from
USECALLBACK_RE.search(component_source)on the entire joined string to iterating lines with substring check first (if "useCallback" in l), then regex only when needed. This avoids regex on large text and short-circuits on first match.Performance Impact by Workload
The optimization particularly benefits:
test_large_scale_detection_performanceandtest_detection_accuracy_with_1000_itemstest_many_inline_props_in_large_componentandtest_complex_nested_jsx_structuretest_many_function_definitionsThe approach maintains identical detection logic and results while dramatically reducing computational cost through algorithmic improvements: O(n) substring checks filter out non-matching lines before expensive O(n*m) regex operations.
✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr1561-2026-02-20T03.10.31and push.