Repository navigation
Conversation
It is unused since 3ccabc6
We are computing the display column of a position by decoding every char from the start of its line for the location of every possible panic, so a file with very long lines takes quadratic time. (This is the case for a generated file that can get very long lines) For most code (ascii without tabs) the column is the byte index. So optimize the fast path. On a ~5 MB generated single line file, the build goes from 161s to 15s
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| } | ||
|
|
||
| let (lines, multibyte_chars) = analyze_source_file::analyze_source_file(&src); | ||
| let may_contain_tabs = src.contains('\t'); |
There was a problem hiding this comment.
I considered trying to do this in analyze_source_file::analyze_source_file doing that at the same time as breaking lines and detecting non-ascii, but that is more involved and i hope contains is optimized enough already.
|
I assume you want to measure this? @bors try @rust-timer queue Also note that this likely interacts with LLM policy: https://forge.rust-lang.org/policies/llm-usage.html |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Optimize display column calculation
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (b0e2506): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 0.4%, secondary 1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -0.5%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 487.289s -> 487.926s (0.13%) |
We are computing the display column of a position by decoding every
char from the start of its line for the location of every possible panic,
so a file with very long lines takes quadratic time.
(This is the case for a generated file that can get very long lines)
For most code (ascii without tabs) the column is the byte index.
So optimize the fast path.
On a ~5 MB generated single line file, the build goes from 161s to 15s
LLM disclosure: an AI agent was used to diagnose the issue and first iteration, but the patch was then iterated and simplified by me.