⚡️ Speed up method JavaScriptSupport._format_js_line_profile_output by 16% in PR #1561 (add/support_react)#1592
Conversation
The optimized code achieves a **15% runtime improvement** (4.56ms → 3.93ms) through several targeted optimizations that reduce overhead in the formatting loop:
**Key Performance Improvements:**
1. **Pre-computed format strings** - Moving format string definitions (`header_format`, `data_format`, `separator`) outside the loop eliminates redundant string parsing on every iteration, saving ~2% overhead per file.
2. **Division-to-multiplication optimization** - The most impactful change: computing `time_factor = 100.0 / total_time_ms` once and using multiplication (`pct = time_ms * time_factor`) instead of division in the inner loop. This reduces the percentage calculation from 8.5% to 5.2% of runtime - a **42% speedup** on this operation. Multiplication is significantly faster than division in CPU cycles.
3. **Direct dictionary access in sum()** - Changed from `data.get("time_ms", 0)` to `data["time_ms"] if "time_ms" in data`, reducing method call overhead in the total time calculation (though this remains at ~10% of runtime).
4. **Cached timings lookup** - Storing `parsed_results.get("timings", {})` once avoids repeated dictionary lookups across iterations.
5. **str.format() over f-strings** - While f-strings are generally fast, `str.format()` with pre-built format strings can be more efficient in tight loops with repeated formatting patterns, reducing the formatting overhead from 42.6% to 42.4% of total time.
**Test Results Show Optimization Strength:**
The speedup scales with data size - larger test cases see the most benefit:
- `test_large_scale_many_lines_produces_expected_number_of_output_rows`: **18.5% faster** (1.15ms → 973μs)
- `test_complex_large_scale`: **18.4% faster** (1.29ms → 1.09ms)
- `test_large_single_file`: **15.1% faster** (133μs → 116μs)
- `test_many_lines_per_file_100`: **17.6% faster** (126μs → 107μs)
This demonstrates the optimization is most valuable when formatting many profiling lines, which is the typical use case for line profiler output. The micro-optimizations compound effectively across iterations, making this change particularly beneficial for real-world JavaScript profiling scenarios with hundreds or thousands of lines.
| hits = data.get("hits", 0) | ||
| time_ms = data.get("time_ms", 0) | ||
| pct = (time_ms / total_time_ms * 100) if total_time_ms > 0 else 0 | ||
| content = data.get("content", "") | ||
| # Truncate long lines for display |
There was a problem hiding this comment.
Nit: duplicate comment — "Truncate long lines for display" appears here and again at line 2294. The first one seems out of place (it's before the percentage calculation, not the truncation). Consider removing this one.
PR Review SummaryPrek ChecksFixed - 12 auto-fixable issues resolved in
Committed and pushed as MypyNo new mypy issues introduced. The PR actually reduces mypy errors in changed files from 37 → 26 (pre-existing errors on main). Code ReviewThis is a codeflash optimization PR targeting
Minor issue: Duplicate "Truncate long lines for display" comment (see inline comment). No critical bugs, security issues, or breaking API changes found in the PR diff. Test CoveragePR branch (1 failure in unrelated
Notes:
Last updated: 2026-02-20T09:00:00Z |
⚡️ This pull request contains optimizations for PR #1561
If you approve this dependent PR, these changes will be merged into the original PR branch
add/support_react.📄 16% (0.16x) speedup for
JavaScriptSupport._format_js_line_profile_outputincodeflash/languages/javascript/support.py⏱️ Runtime :
4.56 milliseconds→3.93 milliseconds(best of225runs)📝 Explanation and details
The optimized code achieves a 15% runtime improvement (4.56ms → 3.93ms) through several targeted optimizations that reduce overhead in the formatting loop:
Key Performance Improvements:
Pre-computed format strings - Moving format string definitions (
header_format,data_format,separator) outside the loop eliminates redundant string parsing on every iteration, saving ~2% overhead per file.Division-to-multiplication optimization - The most impactful change: computing
time_factor = 100.0 / total_time_msonce and using multiplication (pct = time_ms * time_factor) instead of division in the inner loop. This reduces the percentage calculation from 8.5% to 5.2% of runtime - a 42% speedup on this operation. Multiplication is significantly faster than division in CPU cycles.Direct dictionary access in sum() - Changed from
data.get("time_ms", 0)todata["time_ms"] if "time_ms" in data, reducing method call overhead in the total time calculation (though this remains at ~10% of runtime).Cached timings lookup - Storing
parsed_results.get("timings", {})once avoids repeated dictionary lookups across iterations.str.format() over f-strings - While f-strings are generally fast,
str.format()with pre-built format strings can be more efficient in tight loops with repeated formatting patterns, reducing the formatting overhead from 42.6% to 42.4% of total time.Test Results Show Optimization Strength:
The speedup scales with data size - larger test cases see the most benefit:
test_large_scale_many_lines_produces_expected_number_of_output_rows: 18.5% faster (1.15ms → 973μs)test_complex_large_scale: 18.4% faster (1.29ms → 1.09ms)test_large_single_file: 15.1% faster (133μs → 116μs)test_many_lines_per_file_100: 17.6% faster (126μs → 107μs)This demonstrates the optimization is most valuable when formatting many profiling lines, which is the typical use case for line profiler output. The micro-optimizations compound effectively across iterations, making this change particularly beneficial for real-world JavaScript profiling scenarios with hundreds or thousands of lines.
✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr1561-2026-02-20T08.39.24and push.