⚡️ Speed up function _create_operator_expression by 24%
#100
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.
📄 24% (0.24x) speedup for
_create_operator_expressioninaerospike_helpers/expressions/resources.py⏱️ Runtime :
109 microseconds→88.5 microseconds(best of8runs)📝 Explanation and details
The optimization achieves a 23% runtime improvement (109μs → 88.5μs) through two key changes:
1. Stack-Based Traversal in
compile()(Primary Speedup)The original code used
itertools.chain()with generator-based iteration, callingnext()repeatedly. The optimized version replaces this with a list-based stack that uses.pop()and.extend()operations. This eliminates:chain()StopIterationnext()Python's list operations (
.pop(),.extend()) are implemented in C and are significantly faster than generator-based iteration for this use case. The children are reversed when pushed onto the stack to maintain proper processing order.2. Explicit Tuple Conversion in
_create_operator_expression()The original unpacking syntax
(*left_children, *right_children)performs implicit type conversion and creates intermediate objects. The optimized version:isinstance()checks (fast type checks in Python)_overload_op*methods)+) which is a C-level operationLooking at
function_references,_create_operator_expression()is called from operator overload methods (__add__,__sub__,__mul__, etc.) which are likely in hot paths when building complex expression trees. The optimization reduces allocation overhead when chaining multiple operators.Test Results
The optimization shows significant gains (36-92% faster) for large-scale scenarios with many children (100-600 elements), while maintaining correctness for all edge cases. Small regressions in some micro-benchmarks (mostly < 7%) are overwhelmed by the substantial gains in realistic workloads, resulting in the overall 23% runtime improvement.
✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-_create_operator_expression-ml0hyh3rand push.