savannah: strange behavior with viewing files >2Gb

[slavazanko]

Original: ​http://savannah.gnu.org/bugs/?15749

Submitted by:	yaroslav <s68>	Submitted on:	Tue 14 Feb 2006 09:07:15 AM UTC
Category:	Viewer	Severity:	3 - Normal
Status:	Confirmed	Privacy:	Public
Assigned to:	Roland Illig <rillig>	Open/Closed:	Open
Release:	current (CVS or snapshot)	Operating System:	All

Discussion:

Fri 04 Aug 2006 11:55:16 AM UTC, comment #5:

Maybe my conclusion was a bit hasty. It is indeed useful to be able 
to scroll up from the end of the file.

Maybe the current logic should be extended with a "from end of 
file" logic. Line cache should only be filled when a goto is 
executed, and while the user is scrolling through the file (either 
down from the top, or up from the bottom).

Reopening.
	Leonard den Ottolander <leonardjo>
Project Member
Fri 04 Aug 2006 11:31:34 AM UTC, comment #4:

Try F5 to a line around the end of the file. This might be faster 
in the old viewer. Now goto a line at the beginning of the file. 
Instantaneous in both cases. Now jump to a line at the end of a 
file again. New viewer is instanteneous. Old viewer still takes the 
same time as in the first case.

So if you actually want to view the whole file the new viewer 
behaves better. If you just want to see the tail use tail.

We might want to document this new behaviour:

`"End" now behaves as a "goto" and fills the line cache which might 
take a long time on large files. Jumping through the file is 
actually improved. Use "tail" if you only want to view the tail of 
a file.`

Closing "not a bug".
	Leonard den Ottolander <leonardjo>
Project Member
Fri 24 Feb 2006 09:39:43 PM UTC, comment #3:

I have almost same problem, but my mc reads entire file whenever I 
press END key in every text file. Small files doesn't count, but eq 
120MB+ logs on a busy server matters.
mc-4.6.1a-4.FC4 few instances on few machines, i386.rpms and 
recompiled from sources - no diffrence.
	Pawel Misiak <pavelsky>
Tue 14 Feb 2006 02:20:14 PM UTC, comment #2:

> Did I understand you correctly that scrolling to the end of a 
file < 2 GB is momentarily, but it takes long only for files > 2 GB?

Yes.

> There is currently no way to avoid the waiting. It is used for 
line number generation, and perhaps that calculation could be 
delayed a bit or be done in the background.

So sorrow :-/ But it is strange for me that time of calculation 
significantly increases just at point of 2Gb...
	yaroslav <s68>
Tue 14 Feb 2006 10:28:56 AM UTC, comment #1:

It's true that the viewer takes a long time to scroll at the end of 
a large file.

Did I understand you correctly that scrolling to the end of a file 
< 2 GB is momentarily, but it takes long only for files > 2 GB? I 
would have expected it the other way round, so that files < 2 GB 
take a long time and files > 2 GB are quick (which might indicate a 
bug in the code).

There is currently no way to avoid the waiting. It is used for line 
number generation, and perhaps that calculation could be delayed a 
bit or be done in the background. This would complicate the code, 
as the current commands for "one line up", "one line down", and so 
depend on the line numbers to be there. But it is certainly 
possible.

Roland
	Roland Illig <rillig>
Project MemberIn charge of this item.
Tue 14 Feb 2006 09:07:15 AM UTC, original submission:

While trying to scroll to end of large file mc reads all of the 
file, that can continue up to couple of minutes. While viewing 
large but <2Gb file scrolling to end is momentally. Bug (?) appears 
in FreeBSD & MacOS X.