bugGNU nano - Bugs: bug #50399, constant position display...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #50399: constant position display (--constantshow) is very slow

Submitter:  Sworddragon <sworddragon>
Submitted:  Sat 25 Feb 2017 02:02:43 PM UTC
   
 
Severity:  3 - Normal Status:  Works For Me
Assigned to:  None Open/Closed:  Closed

Mon 02 Dec 2019 08:33:18 AM UTC, comment #3: 

(The effective speedup was achieved with version 3.0.  Reading in a file became faster, but also the handling of pure ASCII text became much faster.)

Benno Schulenberg <bens>
Group administrator
Sun 01 Dec 2019 04:31:50 PM UTC, comment #2: 

With a recent nano, running 'nano --ignore --constant million' and typing M-/ to go to the end of the buffer is quite quick: less than half a second (even on my old Atom-powered laptop).  Reading in the file takes longer: about a second and a half.  So... this is not a problem any more, it seems -- at least not with plain ASCII files.  So I will let this be.

Benno Schulenberg <bens>
Group administrator
Sun 26 Feb 2017 12:35:57 PM UTC, comment #1: 

(The issue with reading in a large file has been rereported as bug #50406.  The current bug will be only about --constantshow.)

To reproduce, run 'for x in $(seq 45); do cat src/*.c >>million; done'.  Open the file: 'nano --ignore --constant million'.  Type <Down> a few times.  Nano responds virtually instantly.  Now type M-/.  It takes eight seconds before nano finally shows the bottom of the file.  This is unusable.  Now type <Up> a few times quickly in a row.  It takes nano again eight seconds to show the result of the first <Up>, and another eight seconds to show the result of the rest of the keystrokes.  Useless.

With constant position display, nano recomputes the number of characters up to the position of the cursor /every/ time the cursor is moved.  This is an enormous waste of time.

If you open the same file with Pico, the result of typing ^C is nearly instantaneous, wherever the cursor is in the file.  I am guessing that Pico stores the number of characters that each line contains, and when ^C is pressed, it quickly adds up all these numbers of the lines before the cursor, plus the number of characters on the current line before the cursor.  Nano should do something similar, because recounting all the characters up to the cursor for every keystroke is utterly wasteful.

This is not so easy, though: when cutting or pasting text, things can be cut or inserted midline, so it will take a lot of extra hassle to get the character counts for each affected line right.

Benno Schulenberg <bens>
Group administrator
Sat 25 Feb 2017 02:02:43 PM UTC, original submission:  

I'm using nano 2.7.4 and I'm noticing that the performance is not that good in some cases:

- Opening a log file that has a size of 235 MiB needs a bit over 10 seconds to open. This is not very bad but maybe this can be enhanced a bit.

- But the main issue is that using "set const" does decrease the performance very fast if a few tenthousand lines are reached. This seems to get even worse if going down is continued.

Sworddragon <sworddragon>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by sworddragon (Submitted the item)
  •  

    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
    2019-12-01 bens StatusNone Works For Me
        Open/ClosedOpen Closed
    2017-02-26 bens SummaryPerformance is not optimal constant position display (--constantshow) is very slow

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code