bugGNU nano - Bugs: bug #48389, typing a key during loading slows...

 
 

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

bug #48389: typing a key during loading slows things down terribly

Submitter:  Benno Schulenberg <bens>
Submitted:  Sun 03 Jul 2016 03:45:40 PM UTC
   
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Thu 14 Jul 2016 12:51:17 PM UTC, comment #2: 

The abortion mechanism was removed from git, afb6a5b.

Benno Schulenberg <bens>
Group administrator
Mon 04 Jul 2016 10:11:29 AM UTC, comment #1: 

Well, things only get slow when using a syntax that doesn't really apply to the file.  When doing 'for x in $(seq 9); do cat src/*.c >>200thousand.c; done', and then running 'src/nano +199999 200thousand.c' and typing a key during startup (say ^N), things respond normally, there is no slowness at all.  Also not when typing Enter (see bug #48386).  This is because this is a real C file, with a normal distribution of multiline comments, so resets of the multiline data don't go very far, and reevalution also has to look at just a few handfuls of lines.

However, remains the fact that when typing anything during startup and using a syntax with a heavy multiline rule (like python), we actually lose startup speed (when the target position is not somewhere near the head of the file) and afterward any movement during this session with this file will be slower.  So this "abortion" mechanism of the precalculation routine doesn't pay, it doesn't gain us anything (well, only when opening a really huge file that we haven't looked at before, so it will start displaying on line 1, then cutting short the precalculation may gain us a few seconds -- but then the user has already waited tens of seconds for the file to simply load; surely she can then wait a few seconds more for the multiline data to be precomputed).  And in fact, all this looking at the clock to see whether to poll the keyboard again is only slowing things down.  So I would say: axe it.

Benno Schulenberg <bens>
Group administrator
Sun 03 Jul 2016 03:45:40 PM UTC, original submission:  

To reproduce, run 'for x in $(seq 66); do cat NEWS >>hundredthousand.c; done'. Then run 'src/nano +99999 hundredthousand.c', and see how between the message "Read 100518 lines" and actually displaying the file there is just a brief moment.  Exit from nano and run the same command again, but now hit a key (say "H") shortly after hitting Enter.  See how after "Read 100518 lines" there is a pause of five, six seconds before the file is actually displayed.

This probably is because when there is no precalculated data, nano has to laboriously work its way back to find existing data, and this for every screen line, or for every occurrence of a possible end match -- I'm not sure, it's too complicated.

Even worse, in this situation every PageUp or PageDown also takes those maddening five seconds.  (Of course, an Enter also takes five seconds, but when not typing anything at startup, at least one could move around with normal quickness.)

I think that we should either limit the number of lines that are reset, or otherwise (when working backwards) simply give after a certaing number of lines instead of going back all the way to the top of the file.  That might cause some miscolorings, but that is better than this maddening unresponsiveness.

If a hundred thousand lines take five seconds, then two thousand lines would take a tenth of second.  That sounds like an acceptable delay.  So: when searching backward has not given a result withing 2000 lines, then give up and assume there is no match.  And most likely there isn't, because what would be the point of coloring more than 2000 lines in the same color?  Useless.  Syntax coloring is good for highlihgting short words, or maybe a few lines, or a block of comments of twenty or fifty lines, but much more than that is an abuse.

Oh, and the above delay is with the default C syntax.  When using the snake syntax (-Ysnake, see below), and typing a key right after startup, displaying the file takes nearly two minutes!  :|

syntax "snake"
color brightred "#.*"
color green start=""""([^"]|$)" end="(^|[^"])""""
color brightblue "def"

The big slowdown seems to be located in this part: (^|[^"]).   Without it, things go much quicker.

Benno Schulenberg <bens>
Group administrator

 

(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 (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-30 bens Open/ClosedOpen Closed
    2016-07-14 bens StatusIn Progress Fixed
    2016-07-13 bens StatusNone In Progress
    2016-07-04 bens Severity3 - Normal 2 - Minor
        Assigned toNone bens

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code