GNU nano - Bugs: bug #61799, colorizing very long lines can...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61799: colorizing very long lines can take ages
Submitter: | easyaspi314 <easyaspi314> | ||
Submitted: | Wed 12 Jan 2022 05:13:07 AM UTC | ||
Severity: | 3 - Normal | Status: | Fixed |
Assigned to: | bens | Open/Closed: | Closed |
Jump to the original submission
Fri 29 Apr 2022 07:34:08 AM UTC, comment #7: |
Benno Schulenberg <bens> |
Sun 03 Apr 2022 10:38:13 AM UTC, comment #6: The slowdown caused by coloring very long lines has been mitigated in git, commit fe42eb7a, by stopping to paint the line after two thousand bytes.
|
Benno Schulenberg <bens> |
Fri 01 Apr 2022 02:51:16 PM UTC, comment #5: As slightly more realistic reproduction recipe I use this:
|
Benno Schulenberg <bens> |
Tue 22 Feb 2022 11:19:26 AM UTC, comment #4: Highlighting the entire string (before slicing it into displayable chunks) would require a complete rewrite of the coloring routines. Assembling multiple rules into a single super-regex... I don't see how that could work -- how is nano to know whether rules may or may not overlap or recolor previously matched stuff? Using fastmap... that works only with re_search() and we're not using that; and using it would require a complete rewrite of the coloring routines.
|
Benno Schulenberg <bens> |
Wed 12 Jan 2022 05:51:38 PM UTC, comment #3: Additionally, it seems like we can use the GNU extension re_compile_fastmap() to further increase performance, as that will skip over characters that don't match any rules. |
easyaspi314 <easyaspi314> |
Wed 12 Jan 2022 05:31:34 PM UTC, comment #2: When looking at the source code, it seems that we are highlighting each softwrapped line in draw_row() instead of highlighting the line before breaking it.
|
easyaspi314 <easyaspi314> |
Wed 12 Jan 2022 03:05:24 PM UTC, comment #1: One possible mitigation for when syntax highlighting is slowing things down, is to say at the tenth or twentieth start match in a single line: "Fack it. I stop coloring. This is taking too long." That is: add an iteration counter in the main while loop of 'step_two' and break out when counter > 10. That will make the file look ugly, but... |
Benno Schulenberg <bens> |
Wed 12 Jan 2022 05:13:07 AM UTC, original submission:
nano has performance issues on extremely long lines. While this isn't usually a noticable issue, it can affect the following:
|
easyaspi314 <easyaspi314> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-04-29 | bens | Open/Closed | Open | Closed | |
2022-04-03 | bens | Status | Ready For Test | Fixed | |
Summary | inefficient string handling for long lines | colorizing very long lines can take ages | |||
2022-04-01 | bens | Attached File | - | Added stop-coloring-at-4000.patch, #53029 | |
Status | None | Ready For Test | |||
Assigned to | None | bens | |||
2022-01-12 | bens | Summary | Inefficient string handling for long lines | inefficient string handling for long lines |
Powered by Savane 3.13-02a9.
Corresponding source code
The bail-out at two thousand bytes has been released in nano-6.3.