Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a file contains many lines, like 1 million lines, and cat the_file takes too much time to scroll.

$ time cat 1m
......
cat 1m  0.00s user 11.21s system 28% cpu 38.839 total

How to make it faster? Like xterm or urxvt's jumpScroll option?

I'm using PuTTY 0.62 and Windows 8 CP, If Windows 7 is necessary, I can change.


Here is the code I used to generate the file:

#include <stdio.h>

int
main(void) {
        int i;
        for (i = 2; i < 999999; i++) {
                printf("%d\n", i);
        }
        return 0;
}
share|improve this question
1  
Note that if you only want to see the last lines in a file the tail command is better than cating the whole file to the terminal. –  Dan D. Mar 15 '12 at 4:00
    
@DanD, Thank you for let me realized that tail, more, etc are more widely useful than my thoughts, I simple made easy things harder... It's time to change some of my command line using behaviors. However this questions continues, jumpScroll still is a very needed feature. –  Mengdi Gao Mar 15 '12 at 5:14
    
You haven't said what part of the file you want to see. I am assuming the end of the file? A specified line number? –  serotonin Mar 15 '12 at 5:25
    
@serotonin I'm not meant to see the any part of the file, I want to cat or run a program which print 1 million lines to the stdout, and the PuTTY costs 38 seconds to finish this, so I ask if this can be faster. –  Mengdi Gao Mar 15 '12 at 5:30

2 Answers 2

You can't. This is why we shouldn't log to stdout from our inner loops.

Meaningful logging can be implemented with modulus operations, but I get from your comments that you are asking if you can speed up putty.

Printing to stdout is viewing the file, in essence. Writing 'blind' to a file will be much faster, but this time lag you experience is pretty constant.

share|improve this answer

1. Use a program that supports Jumpscroll

E.g. Vandyke software's SecureCRT has some similar sounding features.

2. Choose a better solution for the objectives

It is never sensible to want a human to read 1000000 lines of text in less than 38 seconds. You probably want:

  • A visible indicator of ongoing progress (indicating that the program is still working)
  • Access to the last 20 or so lines of text if the program appears to have paused or stopped.

Normally it is sufficient to just redirect output to a file. You can monitor the size of the file to see if it is growing or static.

If necessary, I'd write a small script that reads lines from STDIN, writes dots to STDOUT (e.g. one dot per n lines or one dot if there has been input on STDIN in the last 1/nth of a second) and retains the last 20 lines for display under some circumstance (EOF, receipt of a signal, etc)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.