[Patch, libgfortran] PR 25561 Part 0.9/2 Get rid of alloc stream

Janne Blomqvist blomqvist.janne@gmail.com
Tue May 6 06:33:00 GMT 2008


Jerry DeLisle wrote:
> Janne Blomqvist wrote:
>> Hello,
>>
>> this is an almost complete patch for part I of getting rid of the alloc
>> stream facility (the low level libgfortran I/O stuff). The patch
>> converts all users of salloc_* to the sread/swrite/sseek interface, with
>> the exception of write_x(). The exception is an issue with T/TL edit
>> descriptors, and as it turns out these don't work correctly now either,
>> see PR 36142. See the PR for some ideas on how to solve it.
>>
> 
> One idea I was kicking around once was to scan the format string, 
> interpreting the edit descriptors and pre-computing the length of the 
> resulting record.  Then this length of buffer could be allocated, write 
> to that buffer, send the buffer to output and free the memory.  This way 
> the buffer automatically adjusts.
> 
> There are other ways to do this as well, such as a fixed size buffer and 
> then increase it as you go.  But in that case you incur a small penalty 
> having to recopy the data to the next size up buffer.
> 
> I am sure we can settle on an approach, keeping in mind most formatted 
> output will be less than 120 characters per record and larger than that 
> is the exception.

I think it could be hard to figure out the size of the buffer just by 
scanning the format string, like Thomas already said. E.g. what about 
variable-width edit descriptors like 'i0', 'f0.x', or 'a'? That being 
said, one could scan the format string in order to get a rough estimate 
of the needed size, and if it turns out to not be enough later on, 
realloc and copy like you suggest. On the other hand, the performance of 
malloc/free is roughly constant wrt the size, so one could play it safe 
and start with something quite large, say one page (4 KB), in order to 
hopefully avoid having to realloc and copy.

In any case, I think it's necessary to scan the format string on the 
first pass through formatted_transfer_scalar, since one has to find out 
whether the format string contains T or TL which would require the extra 
buffer. If the format string doesn't contain T/TL, we know that we don't 
need to go backwards in the record, and we can directly output to the 
final buffer (swrite/stdio/whatever) just like we do now, thus avoiding 
the extra allocation and copying for the common case.

-- 
Janne Blomqvist



More information about the Fortran mailing list