rmariani@watnot.UUCP (Rico Mariani) (04/14/86)
In article <503@Navajo.ARPA> rokicki@Navajo.ARPA (Tomas Rokicki) writes: > >Finally, for those of you driving SER: or PAR: from C, there is a way to >get much faster output than the default single-character buffered output. >Stick in the following magic lines: > >if ((fp=fopen(iname,"r"))==NULL) > err("! hey, buddy, give me a break") ; /* this your code */ >if (fp->_buff==NULL) > if ((fp->_buff=malloc(BUFSIZ))!=NULL) { > fp->_buflen = BUFSIZ ; > fp->_flags |= _ALLBUF ; > } > >Don't forget to declare malloc (char *malloc()) and include stdio.h. This >works with Manx; haven't tested it with Lattice, and makes things incredibly >faster. For an explanation of how it works, I'd have to explain the I/O >library, and since that belongs to Manx, I'm not sure I can legally do that. >It won't screw up i/o to disk, either, so I use it in any open that can go >to the printer, serial port, or disk. I believe it will mess up console >I/O (buffering things that go to the screen in huge chunks is not generally >wise), so be careful. Aztec C provides a function called "setbuf" which is supposed to be used to do the above... e.g. if ((fp=fopen(name,"r"))==NULL) err("Huh? What?..."); if ((buf=malloc(BUFSIZ)) != NULL) err("The world just ran out of memory..."); setbuf(fp,buf); I haven't actually tried this yet. Now about buffered I/O to raw: or con: --- if you *don't* buffer the i/o then you're crazy. The output is *slow* ; for every character you try to write AmigaDOS generates a message and sends it to the appropriate driver. The result is that your text appears at about 120 cps. YUCK! Having to remember to flush your output is well worth the price. But there is another problem, suppose that you happen to know that stdout is going to be connected to con: most of the time. You want the text to appear quickly but you can't use the setbuf call because you didn't open the file and a buffer may or may not have already been allocated for you. Hmmmm... well first you can try Tomas's code above, that might get you out of the mess (I haven't tried that yet myself) but that failing you have to change getbuff (the routine that does the automatic buffer allocation) so that even output that is a connected to con: or raw: is buffered. Currently getbuff checks to see if the file is going to be connected to a "tty" and if so it allocates a 1 character buffer. This is a *big* lose because it's too slow! So now that you've somehow got the buffering that you wanted on your favourite output stream you're getting annoyed because you've got to go fflush(stream) after every block of output. Well there is one more kludge that is worth installing. Unix normally flushes a stream that is connected to a tty after every newline... this is pretty kludgy but it is effective (I have a feeling this is what Lattice did, but I'm not sure -- Aztec doesn't have this problem because they don't buffer tty's) Other than a few problems with the standard i/o library (which I had no trouble fixing seeing as I paid for the source...) Aztec C has impressed me... The executable modules are about half the size and run twice as fast. The compiler itself is much faster than Lattice and you get a real "make", their Z editor (which still is missing some features...), library/archive maintainance stuff, and a first approximation to a symbolic debugger. Overall I am quite pleased with the package. Enjoy! -Rico ...{ihnp4|allegra|linus|decvax|utzoo}!watmath!watnot!rmariani in 7 days I'll be ...{ihnp4|allegra|linus|decvax|watmath}!utzoo!oscvax!rico (the first address will be forwarded to the second for quite some time...)