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

Submitted by:  Sworddragon <sworddragon>
Submitted on:  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>
Project 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>
Project 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>
Project 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>


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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    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.5