Thread: Faster way of printing to the screen

  1. #1
    Registered User
    Join Date
    Feb 2009
    Posts
    1

    Faster way of printing to the screen

    Hi,

    I'm looking for a method or a system call procedure that can print to the screen much faster than printf. There is this tool that i'm writing that generates a lot of output. And printing that onto the screen takes a long time ... so i was hoping to find something that is faster. Ages ago, i had written a text editor (15yrs back) where i came across the same problem (Displaying the text on the screen while pressing the page down key was slowing things down a lot). And i got around that by accessing the video buffer and writing to it directly. This was a lot faster, and now i don't seem to remember how exactly i did it.

    Can anyone help?

    Thanks!

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    What hardware are you using?!!?!!

    It seems to me that printf on any modern computer will print to the screen about ten thousand times faster than you could ever actually read it, and you will have to since it disappears into your console line buffer right away. The speed at which data that you can't read now is printed seems irrelevent, unless you mean you just want to get it over with. If that's the case, or it's just the end of the input that you want, modify the code to PRINT LESS, not to print tons of stuff that you can only ignore.

    The issue with "page down" may or may not be related to printf.

    You could substitute fprintf and put all that garbage in a file, which will be much faster (or sprintf and put it into a RAM buffer, which will be like instantly fast). Then just use some kind of tail command on the file to get the end of it,etc.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    Registered User
    Join Date
    Feb 2009
    Posts
    138
    write to a file then echo the file with system() when it's done.

  4. #4
    Registered User
    Join Date
    Dec 2007
    Posts
    2,675

  5. #5
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    printf() has to do a lot of string parsing before it prints anything to the screen. If you don't need the special string parsing, puts() should be faster, either that or use an OS API call.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  6. #6
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    You want to print data as quickly as possible so that:

    A) Some other program can read it as quickly as possible
    or
    B) YOU can read it as quickly as possible.

    In the first case, how would you communicate the data to another program by writing to the frame buffer?

    In the second case, how could you possibly read text faster than a computer can generate it?

    I'm thinking it's got to be the former scenario, in which case you can't do much better than fwrite() or fputs().
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    Could you expand on the echo of a file with system() please?


    In the old days, color video memory began at B800:0000, for most (not all) color video cards. In Turbo C/C++ you had a global variable that you could change in a header file, that determined if you wrote directly to video memory, or if you wrote to video memory only by using the OS.

    You had to be 100% compatible with the IBM PC standard at the BIOS level to make the faster video memory writing possible.

    But that was DOS, and we're a long way from DOS these days. I used to be able to use clrscr in C, but since I have a newer monitor now, the driver is different, and clrscr in Turbo C/C++ no longer works. In QuickBasic, CLS works, but only for part of the screen, now.

    As I understand it, the difference now is primarily that DOS had segmented memory, and video memory was given FAR memory segment. Now we have a non-segmented memory for the video memory, so all the FAR pointers and call using them, are no longer supported.

    If you want to print to the monitor as fast as possible, I'd assemble each line in a buffer, with an end of string char on the end, and then use puts(), instead of printf, to print it out. printf is many times more complex and much slower than a single and simple call to puts().

    I don't know if the Windows API has anything to help with this, or not.

  8. #8
    Registered User
    Join Date
    Feb 2009
    Posts
    138
    Could you expand on the echo of a file with system() please?
    Code:
    #include <stdio.h>
    #include <stdlib.h>
    
    void echo(char *file);
    
    int main()
    {
        char *tmp = tmpnam(NULL);
        FILE *fp = fopen(tmp, "w");
        int i;
        for (i = 0; i < 1000; i++) fputs("hello world!\n", fp);
        fclose(fp);
        echo(tmp);
        remove(tmp);
        return EXIT_SUCCESS;
    }
    
    void echo(char *file)
    {
        char cmd[20];
        sprintf(cmd, "type %s", file);
        puts(cmd);
        system(cmd);
    }

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    If you are doing something like scrolling on screen (e.g. page-down in text editor), then you can indeed do that quicker than printf, since printf goes quite a long way around to achieve it's output. In particular, if we are talking windows, you can use the Console Functions.

    The ScrollConsoleBuffer is also useful for page-down/up type actions if you don't want to scroll the ENTIRE buffer.

    The console functions is what printf() eventually ends up in - but there's several layers of other code inbetween.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    Echo just displays (or not), system commands on the screen. Useful for bat files and such.

    Here, you've named your function "echo", but it doesn't use echo at all- it uses the "type" <filename> command.

    Very slick try, however. You had me going there for a minute.

  11. #11
    Registered User
    Join Date
    Feb 2009
    Posts
    138
    i wasn't try to trick you. you made an assumption, and i think you know how that goes.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Adak View Post
    In the old days, color video memory began at B800:0000, for most (not all) color video cards. In Turbo C/C++ you had a global variable that you could change in a header file, that determined if you wrote directly to video memory, or if you wrote to video memory only by using the OS.

    You had to be 100% compatible with the IBM PC standard at the BIOS level to make the faster video memory writing possible.

    But that was DOS, and we're a long way from DOS these days. I used to be able to use clrscr in C, but since I have a newer monitor now, the driver is different, and clrscr in Turbo C/C++ no longer works. In QuickBasic, CLS works, but only for part of the screen, now.

    As I understand it, the difference now is primarily that DOS had segmented memory, and video memory was given FAR memory segment. Now we have a non-segmented memory for the video memory, so all the FAR pointers and call using them, are no longer supported.

    If you want to print to the monitor as fast as possible, I'd assemble each line in a buffer, with an end of string char on the end, and then use puts(), instead of printf, to print it out. printf is many times more complex and much slower than a single and simple call to puts().

    I don't know if the Windows API has anything to help with this, or not.
    Why do you keep bringing up Turbo C/C++ & extremely unportable and bad solutions?
    Many have suggested viable solutions, yet all you come with is always, always Turbo C/C++ and low-level stuff that's not viable today.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    Quote Originally Posted by Elysia View Post
    Why do you keep bringing up Turbo C/C++ & extremely unportable and bad solutions?
    Many have suggested viable solutions, yet all you come with is always, always Turbo C/C++ and low-level stuff that's not viable today.
    I have a lot of old Turbo C/C++ programs that I'm now porting over to VS C++, and these "legacy" factors, do come into play.

    Note that the OP brought up direct video access, himself:
    Ages ago, i had written a text editor (15yrs back) where i came across the same problem (Displaying the text on the screen while pressing the page down key was slowing things down a lot). And i got around that by accessing the video buffer and writing to it directly. This was a lot faster, and now i don't seem to remember how exactly i did it.
    I mentioned direct video writing, because he asked specifically about it.

    I also mentioned that it didn't work today, afaik, and suggested he put his data to be printed into a string in RAM, and print it out with puts().

    Why is using puts() an "extremely unportable and bad solutions"?

    That was my suggestion, but you didn't read that far along, did you?

    You're not being 100% objective here. There are millions of legacy C programs, and there are still students who are required to use some legacy C IDE. I don't believe there is any reason to ignore their questions, and I don't believe there is any reason to get upset about seeing a reply to them that deals with legacy C features.

  14. #14
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Adak View Post
    I have a lot of old Turbo C/C++ programs that I'm now porting over to VS C++, and these "legacy" factors, do come into play.
    I'm sure you have to battle with it, but you keep bringing it up to others, about using Turbo C/C++ and presenting a lot of old code.
    Not usually a good thing.

    Note that the OP brought up direct video access, himself:
    I mentioned direct video writing, because he asked specifically about it.
    I also mentioned that it didn't work today, afaik, and suggested he put his data to be printed into a string in RAM, and print it out with puts().
    You also mentioned a whole lot of other things like
    In QuickBasic, CLS works, but only for part of the screen, now.
    It sounded as if you wanted to present other options...

    Why is using puts() an "extremely unportable and bad solutions"?
    That was my suggestion, but you didn't read that far along, did you?
    No, no, no. Never was referring to puts. I read the whole post.

    You're not being 100% objective here. There are millions of legacy C programs, and there are still students who are required to use some legacy C IDE. I don't believe there is any reason to ignore their questions, and I don't believe there is any reason to get upset about seeing a reply to them that deals with legacy C features.
    I'm just asking, not blaming, because you seem to suggest things concerning Turbo C/C++ a lot, while others try to help in other ways.
    But I do believe it's a bad idea to present old code instead of trying to find solutions with newer code.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    I would guess that if it's too slow that it's because the OP is Printf-ing one character at a time. That's the usual story!
    If not, post some code!
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Render text
    By Livijn in forum C++ Programming
    Replies: 6
    Last Post: 07-06-2007, 03:32 PM
  2. Printing \n on the screen in C
    By swgh in forum C Programming
    Replies: 4
    Last Post: 05-18-2007, 03:52 PM
  3. char copy
    By variable in forum C Programming
    Replies: 8
    Last Post: 02-06-2005, 10:18 PM
  4. question about printing on screen and not overwriting text...
    By revelation437 in forum C Programming
    Replies: 2
    Last Post: 12-14-2002, 02:48 PM
  5. Printing out contents of a file to the screen
    By Simon in forum C Programming
    Replies: 18
    Last Post: 10-21-2002, 08:05 AM