GNU nano - Bugs: bug #62056, screen-drawing at the end of a...
You are not allowed to post comments on this tracker with your current authentication level.
bug #62056: screen-drawing at the end of a large XML file is too slow
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Tue 15 Feb 2022 04:12:37 PM UTC | ||
Severity: | 3 - Normal | Status: | Fixed |
Assigned to: | bens | Open/Closed: | Closed |
Thu 17 Mar 2022 03:32:13 PM UTC, comment #4: |
Benno Schulenberg <bens> |
Sun 20 Feb 2022 01:34:41 PM UTC, comment #3: However... if we recalculate the multiline data every time a multiline-regex match has changed (or might have changed -- when pasting multiple lines we don't check all the pasted lines), then we can trust the multidata to be correct, but that also means that the drawing routines must not set or changed any of this multidata. In theory the drawing routines would always want to set the multidata to what it already set to, but I'm not sure whether this actually is the case.
|
Benno Schulenberg <bens> |
Sun 20 Feb 2022 12:41:05 PM UTC, comment #2: (It is worth noting that the 324 ms refresh time at the end of the example XML file is caused entirely by the last multiline regex in the xml syntax ('color yellow start="<!--" end="-->"). The only two comments in the example file occur at the start, so when doing backtracking for this regex pair, nano has to recede all the way to the start of the file, to the second of these two comments. Majorly inefficient.) |
Benno Schulenberg <bens> |
Tue 15 Feb 2022 04:51:17 PM UTC, comment #1: This backtracking for the first row is only needed when we made a jump in the file (with M-/, M-PgDn, M-0, Ctrl+↓, after a replacement, ...). That is still for quite a few different movements, but not for all: not for simple scrolls of one row, and not for PageUps and PageDowns. These latter movements are the most common (at least for me) and should be fast, and can be fast.
|
Benno Schulenberg <bens> |
Tue 15 Feb 2022 04:12:37 PM UTC, original submission:
To reproduce, first download the Unicode data file [1], unzip it, and delete the zip file.
It takes several seconds just to load the file. But note the time that precalculation takes (for me 668 ms). Then note the refresh time at the top of the file (for me 11 ms). Now type M-/ to jump to end-of-file. See how long the refresh takes (for me 324 ms). This latter value is too large -- it takes too long, it is too slow.
|
Benno Schulenberg <bens> |
No files currently attached
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-04-29 | bens | Open/Closed | Open | Closed | |
2022-03-17 | bens | Status | None | Fixed | |
2022-02-20 | bens | Summary | screen-drawing at the end of a large file is too slow | screen-drawing at the end of a large XML file is too slow |
Powered by Savane 3.13-4448.
Corresponding source code
Fixed in git, commit 15a0a129, by making sure the multidata is properly precalculated when needed.