PE> summary - cset has the best library, watcom the worst.  pdpclib

PF> ...not the best/worst library --- the best/worst fgets().

Yeah, that's implied by the other results.

PF> Try the same type of program with fseek()/fread() --- IBM's sucks big time 
PF> -- it does a DosBufReset() everytime!

If you only seek to somewhere in the buffer that is already in
memory, mine will just move the internal buffer pointer up a
bit.

PE> creams the lot.  gcc is the best compiler.

PF> Does pdpclib handle crlf cooking?  

Not exactly sure what you mean by "cooking".  MSDOS/OS2 use CRLF
as a newline character, and in text mode, fgets will turn the
CRLF into a '\n', which pdpclib does indeed do.  ADDITIONALLY,
PDPCLIB is designed to accept a non-OS2-standard single '\n' in 
the input file and leave that as a '\n' too.

PF> Is it thread safe?  

I've no idea.  What is thread safe?

PF> I know ibm & watcom 
PF> do, which is bound to add overhead.

And they don't have an option for "normal" text processing
applications that make them double in speed?

PF> Are you ensuring that each CRT is using the same size FILE* buffers?

CRT = Cathode Ray Tube.  No idea what you are asking here.

PE>                 large freads on binary files
PE>                 ----------------------------

PF> oops -- I guess you did try it.

Not sure even what you're saying here!  Try the CRT or what?

PE> summary - Borland has the best library, cset has the worst.
PE> pdpclib creams the lot.  The compilers are equal.

PF> Same questions (I know crlf cooking is not often used by fread/fwrite, but 
PF> it is supported by the others).

fread in binary mode does not allow converting crlf to '\n'.  In
text mode, it does indeed do so.

PE> I used a 486DX33 with a RAM disk in order to perform these tests,

PF> HPFS, with lazy writes,  is often (actually,  most of the time) faster for 
PF> such tests than \os2\vdisk.sys.

I was using a 7 meg file.

PF> Btw -- why go to so much trouble writing a library that already comes with 
PF> each compiler?

The trouble is that the library that comes with each compiler is
copyrighted and has restrictions on it.  Borland even go so far
as to say that if you produce an executable, you must either have
a copyright notice of your own on the exe or say that the exe is
copyrighted by Borland.  No-one let's you just do whatever you 
damn well want.  Since I write PD programs, I don't like the idea
that I should have to put a copyright notice on them.

The other thing is that I often see people using DosRead et al
supposedly for performance reasons, and I didn't believe that
people should have to do that sort of thing, I thought the 
library should be implemented properly so that you don't need
to do rubbish like that.  I have had experience with fgets()
in Borland (DOS) taking 5 times longer than Zortech.  I thought
I could do a better job, basically, if I set out in mind to
concentrate on:
1. making fgets() on text files be as fast as possible.
2. making fread() on binary files be as fast as possible.

That is why I only performance tested those things.  I believe
they are the biggest issues in the C runtime library.  With
fgets(), I spent hours just thinking about the fastest I could
possibly get the central code to go.  I ended up deciding that
the following code...

while ((*u++ = *t++) != '\n') ;

was the best I could do, and then designed the rest of the
library around this one bit of code, making sure I could get
to it via the shortest path possible, at the expense of more
code, or less readability, etc.  The code above can be sped
up a bit (maybe even 20%) by going to assembler.  Actually,
sorry, I already have sped it up a bit by changing it to do
integer moves instead of character moves, so now the scope of
using assembler is probably only 10%, as there's only a couple
of instructions extra generated by the C code cf with 
assembler alternative.  I am loathe to move to assembler yet,
as assembler will make it very messy, and the calling
conventions will need to be taken into account.  BFN.  Paul.
@EOT:

---