RE: Proposed patch for 4 byte unformatted record delimiters

[Bud Davis <bdavis9659 at sbcglobal dot net>]

ummm..a bit controversial as expected.

one performance issue that i have a concern with is
that you like to be able to reserve space for the
leading marker first directly to disk, then the data
(which can be a whole lot of different data types and
sizes that you don't know until they are done), then
the ending marker, then jump back to the leading
marker and stick in the right values.

the last time i looked at the fancy 'expandable
approaches', you had to buffer the whole thing in
memory before writing because you did not know if it
would be a 32 or 64 bit record marker until you saw
all the data.

for a 10K or 100K record, who cares; but for a GB of
data it is a big deal....not only with respect to the
time it takes, but also for how much virtual memory it
consumes.

if someone could (other than me) could make a
description of how it all should work; be it compile
time or link time or an additional option to the open
statement or automatic or some combination of these
oprions; and get some kind of agreement that all
different models of kitchen sink needed are listed, i
will give it another shot. (or alternatively, someone
else can..this is one case where the big picture of
the solution needs to be figured out first).

this is one case where gfortran development has issues
just like my day job....you have to know the
requirements and write them down before you know what
is acceptable.



--bud