⚡️ Speed up function _find_class_node by 14% in PR #1199 (omni-java)
#1252
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 #1199
If you approve this dependent PR, these changes will be merged into the original PR branch
omni-java.📄 14% (0.14x) speedup for
_find_class_nodeincodeflash/languages/java/context.py⏱️ Runtime :
12.3 microseconds→10.8 microseconds(best of91runs)📝 Explanation and details
The optimized code achieves a 14% runtime improvement by eliminating redundant work in a recursive function that traverses abstract syntax trees.
Key Optimization:
The primary performance gain comes from moving the
type_declarationsdictionary to module-level as_TYPE_DECLARATIONS. In the original code, this dictionary was recreated on every recursive call (622 times based on profiler data), consuming ~36% of the function's runtime (lines allocating the dictionary took 8.8% + 6.2% + 6.4% + 5.8% = 27.2% combined). By creating it once at module load time, this overhead is completely eliminated.Additional Micro-optimization:
The code also caches
node.typein a local variablenode_typebefore the dictionary lookup. While this provides minimal benefit (~1-2% based on profiler differences), it slightly reduces attribute access overhead in the hot path wherenode.typewould otherwise be accessed twice (once for theincheck, once for the dictionary lookup on match).Why This Works:
The function performs recursive tree traversal, visiting each node exactly once. Since the type_declarations mapping is constant, recreating it 622 times (once per node visited) is pure waste. Python dictionary creation, even for small dictionaries, involves memory allocation and hash table setup - overhead that compounds significantly in recursive scenarios.
Test Case Performance:
The optimization shows consistent improvements across all test cases (7-20% faster), with the most significant gains in simpler cases like
test_basic_single_class_found(19.8% faster) andtest_missing_name_field_does_not_crash_and_returns_none(16.4% faster). These cases benefit most because a higher percentage of their runtime was spent on dictionary creation relative to other operations. The UTF-8 test case shows smaller gains (11%) because more time is spent in string decoding operations.Impact:
This optimization is particularly valuable when
_find_type_node(or its wrapper_find_class_node) is called frequently on large ASTs, as the savings multiply with tree size and call frequency. The function appears to be used for locating Java type declarations in parsed source code - a common operation in code analysis tools that could be invoked many times during batch processing.✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr1199-2026-02-02T00.29.43and push.