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!

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.

write to a file then echo the file with system() when it's done.

Unbuffered Low-Level I/O

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.

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().

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.

Quote:

---

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);
}

---

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

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. :)

i wasn't try to trick you. you made an assumption, and i think you know how that goes. ;)

Quote:

---

Originally Posted by Adak

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 Elysia

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:

Quote:

---

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.

Quote:

---

Originally Posted by Adak

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.

Quote:

---

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

Quote:

---

In QuickBasic, CLS works, but only for part of the screen, now.

---

It sounded as if you wanted to present other options...

Quote:

---

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.

Quote:

---

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.

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!

Quote:

---

Originally Posted by Elysia

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.

---

I think that those of us who have done this long enough to have used those tools, don't see any point in forgetting everything we learned. The more things change the more they stay the same. We have more bits, more RAM, more storage, yet we continue to write code that's just as crappy as in the "old" days.

A faster processor just means that things can go wrong faster.

We all know that Turbo C is "obsolete" and yet I used it six months ago -- because it was the best tool for the job at hand. Am I seriously getting old enough to be annoyed at people who think the past is worthless?

I'm not trying to suggest that using Turbo C and writing directly to the frame buffer is the right solution to the OP's problem -- I think that would be ridiculous. It just got me thinking.

Quote:

---

Originally Posted by brewbuck

We all know that Turbo C is "obsolete" and yet I used it six months ago -- because it was the best tool for the job at hand. Am I seriously getting old enough to be annoyed at people who think the past is worthless?

---

The past worthless? Never.
In such case, C++ would be retired because Java & C# & Co exists.
No, I do agree with you that something never is not always the best...

Quote:

---

I'm not trying to suggest that using Turbo C and writing directly to the frame buffer is the right solution to the OP's problem -- I think that would be ridiculous. It just got me thinking.

---

It gets me thinking since it's mentioned such a lot. It's old and it's very standards compliant, so it's the least I would like to suggest if it can be helped.
*shrug* That is why I asked.