Ticket #36 (closed defect: invalid) — at Version 8
savannah: strange behavior with viewing files >2Gb
Reported by: | s68 | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.7 |
Component: | mcview | Version: | 4.6.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description (last modified by ossi) (diff)
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 |
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.
Comment 1 by Roland Illig <rillig> at Tue 14 Feb 2006 10:28:56 AM UTC:
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
Comment 2 by yaroslav <s68> at Tue 14 Feb 2006 02:20:14 PM UTC:
> 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...
Comment 3 by Pawel Misiak <pavelsky> at Fri 24 Feb 2006 09:39:43 PM UTC:
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.
Comment 4 by Leonard den Ottolander <leonardjo> at Fri 04 Aug 2006 11:31:34 AM UTC:
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".
Comment 5 by Leonard den Ottolander <leonardjo> at Fri 04 Aug 2006 11:55:16 AM UTC:
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.
Change History
comment:3 Changed 15 years ago by angel_il
- severity set to no branch
- Milestone changed from future releases to 4.7.0-pre3
need check it
comment:6 Changed 14 years ago by andrew_b
- Version set to 4.6.1
- Component changed from mcedit to mcview
Note: See
TracTickets for help on using
tickets.
This behaviour on any big files.