[Patch, Fortran, 4.6, committed] PR 50016: mitigate performance regression on Windows by calling less often _commit

Tobias Burnus burnus@net-b.de
Tue Oct 18 12:59:00 GMT 2011


This patch has been approved by Janne off list - and has been committed 
to the 4.6 branch only (Rev. 180138) after bootstrapping and regtesting it.

It is essentially my patch from
   http://gcc.gnu.org/ml/fortran/2011-10/msg00120.html
minus the .texi change. And the inquire.c part of Janne's patch at
   http://gcc.gnu.org/ml/fortran/2011-10/msg00094.html

In GCC 4.6 and 4.7, every time when the gfortran-internal buffer is 
flushed, _commit() was called on _WIN32 (= MinGW and MinGW-w64), which 
caused a severe slowdown. The reason is that _commit() causes that files 
are written to the hard disk.

With this patch, _commit() is only called when the user explicitly runs 
the FLUSH subroutine/statement. Additionally, if one inquires the size 
of an open file, now the internally known size is used instead of 
calling "stat".

  * * *

For 4.7 the same issue exists but as the release is still a couple of 
months away, we have time to learn more about how Windows handles 
buffering and which consistency should be provided. - The gist of the 
discussion is whether flush() should automatically call _commit or 
whether it shouldn't, which is a question about consistency vs. 
performance. For details, see the thread starting at 
http://gcc.gnu.org/ml/fortran/2011-10/threads.html#00079

For 4.6 we decided that it makes more sense to make the committed patch 
available for 4.6.2 than to delay it further. The patch should fix most 
of the performance issues.

Comment about which strategy to choose for 4.7 and insight about the 
buffering of Windows (i.e. whether it affects data and file meta data 
such as filesizes, or only the latter) are highly welcome.

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commit46.diff
Type: text/x-patch
Size: 3482 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20111018/711e0dd7/attachment.bin>


More information about the Fortran mailing list