From:	khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject:	Re: I/O question
28 Feb 1997 14:52:21 -0800 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<9702281713.AA06758.cygnus.gnu-win32@modi.xraylith.wisc.edu>
Original-To:	Jean-Philippe Chancelier <Jean-Philippe DOT Chancelier AT cergrene DOT enpc DOT fr>
Original-Cc:	gnu-win32 AT cygnus DOT com
In-Reply-To:	Your message of "Fri, 28 Feb 1997 09:59:48 +0100."
	<199702280859 DOT JAA24242 AT deedee DOT cergrene>
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

Jean-Philippe Chancelier <Jean-Philippe DOT Chancelier AT cergrene DOT enpc DOT fr> writes:
> 
> Hello,
> some days ago someone reported that unformated I/O 
> where very slow with GnuWin32 and Fortran code (with f2c or g77) 
> and proposed a solution ? unfortunately I4ve lost that mail 
> and I4d like to get it again.
> 

You can find my comments on libf2c's slow unformatted I/O handling in my
gnu-win32 Web page (along with g77 patches for cygwin32-b17.1). URL after
sig.

This is a general problem with how libf2c handles unformatted I/O records,
specifically how it writes out the record lengths at the beginning of the
record by fseek'ing (and hence flushing the buffers as a side effect). This
is what happens:
    - start a new unformatted record. Remember current record position by
      ftell. <-- causes a fflush()!
    - write out each subrecord and keep a running count of the # of bytes
      written
    - write out the record length at the beginning of the record by
	- remember the end of the record by ftell (another fflush()!)
	- fseek'ing to the beginning (remember the ftell()).
	- write out the length
	- fseek back to the end of the record
    - write out the record length at the end of the record

performance penalty isn't that great on systems with "real" file systems,
on FAT/VFAT, it can be quite bad.

To be fair, it only happens if write *tons* of tiny records. If you write
large records, the penalty is not noticeable.

I had asked the g77 gurus if it is possible to know *how* many bytes will
be written in an unformatted record by prescanning the write statement. If
so, then we can simply write the record length before starting the actual
data write, and no fseek'ing back and forth ...

I didn't really propose a solution, rather showed how I circumvented the
problem by writing the unformatted reader/writer for *our* code in C and
have the FORTRAN routines call the C routines on gnu-win32 and the regular
FORTRAN routines on other systems.

Regards,
Mumit -- khan AT xraylith DOT wisc DOT edu
http://www.xraylith.wisc.edu/~khan/
http://www.xraylith.wisc.edu/~khan/software/gnu-win32

-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -