⚡️ Speed up method ReferenceFinder._find_reexports by 14% in PR #1339 (coverage-no-files)#1362
Merged
KRRT7 merged 1 commit intocoverage-no-filesfrom Feb 4, 2026
Conversation
The optimization achieves a **14% runtime improvement** (702μs → 614μs) by adding an inexpensive pre-check before performing expensive tree-sitter parsing operations. **Key optimization:** The code now checks if the `export_name` exists anywhere in the `source_code` string before calling `analyzer.find_exports()`. This simple substring check (`if export_name not in source_code`) acts as a fast filter to skip files that definitely don't contain re-exports of the target function. **Why this is faster:** 1. **Avoids expensive parsing**: The line profiler shows `analyzer.find_exports()` consumes 45.4% of original runtime (1.37ms of 3.01ms total). The optimized version reduces this to 39.8% of a smaller total (1.02ms of 2.56ms), with 6 out of 25 calls completely avoided. 2. **String containment is O(n)** with highly optimized C implementation in Python, while tree-sitter parsing involves building and traversing an AST, making it orders of magnitude more expensive. 3. **Cascading savings**: When the pre-check fails, we also skip `source_code.splitlines()` (3.2% of original runtime) and all subsequent loop iterations. **Impact:** The profiler shows that in the test dataset, 6 out of 25 files (24%) don't contain the export name and can short-circuit immediately. For codebases with many files that import/re-export from various sources, this ratio could be even higher, making the optimization particularly valuable when searching across large projects. **Trade-offs:** This is a purely beneficial optimization with no downsides - the string check has negligible overhead compared to tree parsing, and it only returns early when the result would have been an empty list anyway.
codeflash-ai
bot
added
⚡️ codeflash
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
1 participant
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 #1339
If you approve this dependent PR, these changes will be merged into the original PR branch
coverage-no-files.📄 14% (0.14x) speedup for
ReferenceFinder._find_reexportsincodeflash/languages/javascript/find_references.py⏱️ Runtime :
702 microseconds→614 microseconds(best of227runs)📝 Explanation and details
The optimization achieves a 14% runtime improvement (702μs → 614μs) by adding an inexpensive pre-check before performing expensive tree-sitter parsing operations.
Key optimization:
The code now checks if the
export_nameexists anywhere in thesource_codestring before callinganalyzer.find_exports(). This simple substring check (if export_name not in source_code) acts as a fast filter to skip files that definitely don't contain re-exports of the target function.Why this is faster:
Avoids expensive parsing: The line profiler shows
analyzer.find_exports()consumes 45.4% of original runtime (1.37ms of 3.01ms total). The optimized version reduces this to 39.8% of a smaller total (1.02ms of 2.56ms), with 6 out of 25 calls completely avoided.String containment is O(n) with highly optimized C implementation in Python, while tree-sitter parsing involves building and traversing an AST, making it orders of magnitude more expensive.
Cascading savings: When the pre-check fails, we also skip
source_code.splitlines()(3.2% of original runtime) and all subsequent loop iterations.Impact:
The profiler shows that in the test dataset, 6 out of 25 files (24%) don't contain the export name and can short-circuit immediately. For codebases with many files that import/re-export from various sources, this ratio could be even higher, making the optimization particularly valuable when searching across large projects.
Trade-offs:
This is a purely beneficial optimization with no downsides - the string check has negligible overhead compared to tree parsing, and it only returns early when the result would have been an empty list anyway.
✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr1339-2026-02-04T01.44.42and push.