Commit 22111ed
authored
Optimize StandaloneCallTransformer._find_balanced_parens
The optimized code achieves a **26% runtime improvement** by replacing character-by-character iteration with regex-based scanning to find special characters (quotes, parentheses, backslashes). This optimization significantly reduces Python-level loop overhead by leveraging compiled regex's C-level string scanning.
**Key optimization:**
- **Original approach:** Iterates through every character in the string (108,802 iterations in profiling), checking each one against quotes and parentheses
- **Optimized approach:** Uses `self._special_char_re.search()` to jump directly to the next relevant character, reducing iterations from ~109K to ~16.5K (85% reduction)
**Why this is faster:**
The regex engine scans through irrelevant characters (letters, numbers, whitespace, operators) at C speed, only stopping at characters that matter for parenthesis balancing. Line profiler shows the main while loop went from 110,858 hits (18.6% of time) to just 18,571 hits (8.2% of time).
**Performance characteristics by workload:**
- **Best speedups (100%+ faster):** Large inputs with long stretches of non-special characters benefit most. Tests like `test_large_many_simple_arguments` (1655% faster) and `test_large_object_and_array_literals_complex` (1485% faster) show dramatic improvements because regex can skip over lengthy argument lists and object literals in one jump.
- **Moderate slowdowns (30-60%):** Small inputs with many special characters pay a regex overhead penalty. Each `regex.search()` call has setup cost, so when special characters are frequent (e.g., `test_deeply_nested_parens_1000` with 73% slower), the optimization's benefits are negated.
- **Trade-off sweet spot:** The optimization excels when the function is called on realistic JavaScript code with long argument lists, string literals, or object/array structures—common in test instrumentation scenarios.
**Impact on workloads:**
Given that `StandaloneCallTransformer` instruments JavaScript test code by finding function call boundaries, the typical use case involves parsing moderate-to-large code snippets with mixed content (strings, nested calls, object literals). The 26% average improvement suggests real-world code has enough non-special character sequences to benefit from regex scanning, making this optimization valuable for the hot path of JavaScript test instrumentation.1 parent f5dd109 commit 22111ed
1 file changed
Lines changed: 16 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
128 | 128 | | |
129 | 129 | | |
130 | 130 | | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
131 | 135 | | |
132 | 136 | | |
133 | 137 | | |
| |||
327 | 331 | | |
328 | 332 | | |
329 | 333 | | |
| 334 | + | |
| 335 | + | |
| 336 | + | |
| 337 | + | |
330 | 338 | | |
331 | | - | |
| 339 | + | |
| 340 | + | |
| 341 | + | |
| 342 | + | |
| 343 | + | |
332 | 344 | | |
333 | 345 | | |
334 | 346 | | |
335 | 347 | | |
336 | | - | |
| 348 | + | |
337 | 349 | | |
338 | 350 | | |
339 | 351 | | |
| |||
347 | 359 | | |
348 | 360 | | |
349 | 361 | | |
350 | | - | |
| 362 | + | |
| 363 | + | |
351 | 364 | | |
352 | 365 | | |
353 | 366 | | |
| |||
0 commit comments