This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
- From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 18 Apr 2013 01:21:42 +0000
- Subject: [Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
- Auto-submitted: auto-generated
- References: <bug-56981-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2013-04-18 01:21:42 UTC ---
I like Jannes idea with the flags. Also, it seems that at the time we open a
file we know it is /dev/null or /dev/nul in some cases by the file name. It
would be very low overhead in a few cases to disable some or all checks and
even disable the writing completely. We would not get all situations, but the
low hanging fruit we could. It could be done by setting a "NULL" bit.
One could consider doing this at compile time in some cases where the frontend
could have more elaborate configuration checks that determine the name of the
null device on the target system and look for its use. (probably not really
worth if fur NULL I/O
The other idea to consider is a compiler flag, say -fast-IO or similar that
also disables the extra error checking that is not critical to runtime after a
program has been debugged.