PE> Peter, on 1996-01-17 I posted two messages to you.  Just

I hope these are the ones  you want....

Area 20, Msg#1731, Jan-23-96 02:24:06
   From: Peter Fitzsimmons                    
     To: Paul Edwards                         
Subject: pdpclib


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.

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


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,

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

PF> Is it thread safe?  

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

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

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?

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

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.

C RUN TIME.


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.

So?

 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

I would add:

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



--- Maximus/2 3.00