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
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. –  M. 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. –  M. 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

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

This site is currently not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .