[patch, libgfortran] Bug 78549 - [7/8 Regression] Very slow formatted internal file output
Jerry DeLisle
jvdelisle@charter.net
Sun Nov 19 23:10:00 GMT 2017
Hi all,
After the usual considerable digging around I determined that for the test case
doing 1000000 writes to a string that we were allocating 1000000 newunit numbers
and the associated unit structures on the unit treap. Consequently, at the end
of the program, when all left open units are cleaned up and closed, a lot of
time was being burned. We did not benefit from the previously allocated unit
structures saved on the treap that could be reused.
IO operations on strings complete with st_read_done or st_write_done of the
parent IO procedure. To fix the problem, I simply declared newunit_alloc
accessible to transfer.c and invoked it.
Now unit numbers and their associated unit structures are reused as they should
be and internal unit I/O is just a little bit better than on gfortran version 6.
My test results with the test case in the PR are as follows. (I commented out
the intermediate write to stdout for clarity)
Patched trunk:
$ gfc -static pr78549.f
$ time ./a.out
real 0m22.476s
user 0m22.183s
sys 0m0.180s
And gfortran 6:
$ gfc6 -static pr78549.f
$ time ./a.out
real 0m22.790s
user 0m22.633s
sys 0m0.011s
Unpatched gfortran 7:
$ gfc7 -static pr78549.f
$ time ./a.out
real 0m29.915s
user 0m28.750s
sys 0m0.971s
Regression tested on x86-64-linux.
I will commit to trunk in a day and back port to 7 in a few more days if no
objections. The patch is simple.
Regards,
Jerry
2017-11-19 Jerry DeLisle <jvdelisle@gcc.gnu.org>
PR libgfortran/78549
* io/io.h (newunit_free): Add declaration. Clean some whitespace.
* io/transfer.c (st_read_done, st_write_done): Call newunit_free.
* io/unit.c (newunit_free): Change type from static void to void.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr78549.diff
Type: text/x-patch
Size: 3667 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20171119/4cd12762/attachment.bin>
More information about the Gcc-patches
mailing list