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

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

PF> There is no need to _ever_ do a DosResetBuffer() in fseek/fread(). fflush() 
PF> maybe,  but that it not even necessary there.

In answer to your specific question, no I do not use DosResetBuffer()
anywhere.  In fflush() I merely do a DosWrite() to give whatever is
in my internal buffer to OS/2.

PF> Does pdpclib handle crlf cooking?  

PE> Not exactly sure what you mean by "cooking".  MSDOS/OS2 use CRLF
PE> as a newline character, and in text mode, fgets will turn the
PE> CRLF into a '\n', which pdpclib does indeed do.  ADDITIONALLY,

PF> The other compilers (ibm/watcom anyway; I no little about emx) you are 
PF> measuring against to this for all file functions,  not just fgets(). I'm 

PDPCLIB does it for all file functions, not just fgets().

PF> sure there's some added overhead there.

Yes, there's overhead in PDPCLIB to do that too.  It still beats
the pants off the rest.

PF> Is it thread safe?  

PE> I've no idea.  What is thread safe?

PF> What will happen if two or more threads use the same 'FILE *' at the same 
PF> time?

Presumably what they deserve.  I have no idea.  This was 
designed to make your ISO C programs as fast as they possibly
could on OS/2.  And pick and choose the compiler on the day.

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

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

PF> IBM has the "subsystem library" (/Rn),  but one of the
things it doesn't 
PF> support if file streams!.   As of version 10,  Watcom combined the single 
PF> and multithreaded libraries (the compiler switch uses the same libraries),  
PF> and I found a very noticeable slowdown in the "single
thread" file streams.  
PF> Try Watcom 9.5 -- it flies.

I don't have Watcom 9.5, I can only compare with what I've got,
and PDPCLIB beats the pants off them.  Anyhow, this file stream
thread-sharing is not something that I was attempting to speed
up.

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

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

PF> C RUN TIME.

Oh, the internal buffer?  Yes indeed.  Well sort of anyway.
PDPCLIB has a default of 6144.  This is the best value I could
find.  I use this for ALL of the compilers.

However, when I am comparing PDPCLIB against the other compilers,
I do not go and do a setvbuf() in order to get them to use the
same (6144) sized buffer.  I expect them to be optimized for my
local system, and if they haven't, that's just another fault with
THEIR implementation.

I do not wish to code setvbuf(..., 6144) on all of my C programs
to make up for slackness in library implementation.  I am happy
to use a decent library implementation that does this automatically.

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

PE> I was using a 7 meg file.

PF> So?

So you want me to run a 7 meg disk cache with HPFS?  The maximum
is 2 meg.  Or are you saying that reading from an HPFS disk is
faster than reading from memory?  I'd like to see that hard
disk!

PE> 1. making fgets() on text files be as fast as possible.
PE> 2. making fread() on binary files be as fast as possible.

PE> That is why I only performance tested those things.  I believe
PE> they are the biggest issues in the C runtime library.  With

PF> I would add:

PF>      3) malloc/realloc/free (these can become an especially nasty
PF>                              bottleneck in a multithread program;  IBM
PF>                              VC++ 3 currently kicks everyone else's
PF>                              pants).

I have never seen malloc et al used so extensively that they
are a bottleneck.  Perhaps that's because I've never written
a multithreaded program in my life.

PF>      4) printf/scanf family

Hmmm, I've never seen anyone who is concerned about performance
to use either of those in code that is a bottleneck.  FWIW I
do a quick check to see if they have put "%s" and then pass it
straight to fgets.  However, I make no real attempt to make
them as fast as possible.  Like I say, my experience in bottlenecks
comes down do fread on binary files, fgets on text files, and
everything else is a bottleneck OUTSIDE the C runtime library.
BFN.  Paul.
@EOT:

---