Commit 041e150
authored
Optimize _BaseExpr.__mod__
The optimized code achieves a **21% runtime improvement** by **inlining the `_create_operator_expression` function call** directly into the `_overload_op` method. This eliminates function call overhead that was consuming 61.2% of the method's execution time in the original implementation.
**Key optimization:**
Instead of calling `_create_operator_expression(l, r, op_type)`, the optimized version constructs the result expression inline:
```python
new_expr = _BaseExpr()
new_expr._op = op_type
new_expr._children = l + r
return new_expr
```
**Why this is faster:**
1. **Eliminates function call overhead**: The original code spent 807μs (61.2% of method time) on the function call itself. The optimized version removes this entirely.
2. **Reduces tuple unpacking**: The original `_create_operator_expression` used `(*left_children, *right_children)` which requires unpacking and repacking tuples. The optimized version uses simple tuple concatenation `l + r`.
3. **Simpler execution path**: Fewer stack frames and attribute lookups result in tighter, more cache-friendly code.
**Test results show consistent improvements:**
- Basic operations: 18-24% faster across all test cases
- Edge cases with complex expressions: 20-24% faster
- Large-scale scenarios (700 combined children): 23.6% faster
The optimization particularly benefits workloads that frequently construct operator expressions, which is common when building complex query filters or database expressions. All behavioral semantics are preserved - the same children tuples are created and the same expression tree structure results.1 parent 4e48bc8 commit 041e150
1 file changed
Lines changed: 4 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
207 | 207 | | |
208 | 208 | | |
209 | 209 | | |
210 | | - | |
| 210 | + | |
| 211 | + | |
| 212 | + | |
| 213 | + | |
211 | 214 | | |
212 | 215 | | |
213 | 216 | | |
| |||
0 commit comments