⚡️ Speed up function _contains_jsx by 149% in PR #1562 (codeflash/optimize-pr1561-2026-02-20T03.10.31)#1568
Merged
claude[bot] merged 1 commit intocodeflash/optimize-pr1561-2026-02-20T03.10.31from Feb 20, 2026
Conversation
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.
Contributor
PR Review SummaryPrek Checks✅ All checks passed — no formatting or linting issues found. Mypy✅ No type errors in the changed file. Code Review✅ No critical issues found. The change converts
This is a safe, behavior-preserving optimization. Test Coverage
Note: This file does not exist on Overall project coverage: 78% (unchanged by this PR). Last updated: 2026-02-20 |
ae71d41
into
codeflash/optimize-pr1561-2026-02-20T03.10.31
22 of 27 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
⚡️ This pull request contains optimizations for PR #1562
If you approve this dependent PR, these changes will be merged into the original PR branch
codeflash/optimize-pr1561-2026-02-20T03.10.31.📄 149% (1.49x) speedup for
_contains_jsxincodeflash/languages/javascript/frameworks/react/profiler.py⏱️ Runtime :
539 microseconds→216 microseconds(best of101runs)📝 Explanation and details
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
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.
Early termination efficiency: Both versions can return
Trueearly when JSX is found, but the iterative version does this more efficiently without unwinding the call stack.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:
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.
✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr1562-2026-02-20T03.28.04and push.