Slow reading from disk file

[dondilworth]

My code reads from a database and loops until it finds a search string:

CHARACTER*16 RJTV,GNAME,NLINE*90


50 READ(JTABLE,6000,ERR=9998) NLINE
LCOUNT = LCOUNT + 1
IF (NLINE(1:1) .LT. 'A' .OR. NLINE(1:1) .GT. 'Z') GO TO 50 ! NAMES ONLY, PLEASE
READ(NLINE(1:16),*) GNAME
IF (RJTV .NE. GNAME) GO TO 50

6000 FORMAT(A90)

This works but is very slow. To search about 4500 lines in the file takes about a second. The same code on a previous CVF version appeared to be instantaneous. In one test, doing 19 of these searches takes about 15 seconds now, and much less than one second before. That's in debug mode. In release mode, with optimization turned on, it is about 1/3 the time -- but the previous version seemed to come back instantly.

Is this a feature of the Intel compiler? Are there any compiler settings that I should change? Here is the command line for the debug version:

/nologo /debug:full /debug:parallel /Oy- /I"Debug/" /recursive /reentrancy:threaded /extend_source:132 /warn:none /Qauto /align:rec4byte /align:commons /assume:byterecl /Qzero /fpconstant /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\\vc100.pdb" /traceback /check:all /libs:static /threads /dbglibs /winapp /c

and, in release mode,

/nologo /debug:full /Oy- /I"Release/" /recursive /reentrancy:threaded /extend_source:132 /Qauto /align:rec4byte /align:commons /assume:byterecl /Qzero /fpconstant /iface:cvf /module:"Release/" /object:"Release/" /Fd"Release\\vc100.pdb" /traceback /check:all /libs:static /threads /winapp /c

I really want this to go faster. Advice, please?

[TimP]

How about /assume:byterecl,buffered_io,protect_parens and removing /check once you have performed sufficient testing?
If you're considering /Oy, a better move would be to X64 (after removing /iface:cvf), but it doesn't look relevant to what you show.

[dondilworth]

Those are excellent suggestions. I found the buffered_io option, but not the protect_parens. Where is that in the Property Pages?

[mecej4]

You can shorten the code to the following:
[fortran]50 READ(JTABLE,6000,ERR=9998) NLINE LCOUNT = LCOUNT + 1 IF (RJTV .NE. NLINE(1:16)) GO TO 50[/fortran] After doing that, and compiling with no checks, with a 4500 line file with 90-character lines consisting of letters and digits, to find the 2603th record CVF 6.6 and IFort 12.1.3 both take about 0.04 seconds on a laptop (i7-2720M) running Window 7 X64.

You have not said how many times you have to do such searches. If many, you can do better by sorting the file and using binary search instead of linear search, or use an indexed file, etc.

You can also read the whole file into memory once and then do your repeated searches on the memory image instead of rereading the disk file.

[dondilworth]

I appreciate the advice. My problem was elsewhere. This is a mixed-language program, and the C++ code was compiled with the /MTd option. When I compile the release version with the /MT option, the Fortran reads are as fast as before. I don't see why a C++ option affects the Fortran performance, but it seems to.

And there is another problem: when I use the buffered io option the program fails to flush the io buffer when it terminates. So a small file that I write out before exiting never gets written to disk. The next time I run the program it cannot read that file. Is there a simple way to get it to flush the buffer before it exits?

And, again, how do I set the paren... option?

[mecej4]

Intel Fortran is dependent on the C/C++ runtime even when building a program (EXE or DLL) solely from Fortran sources. Secondly, having some objects compiled with /MTd and some with /MT can lead to problems, regardless of what source languages were used.

Fortran will flush the buffers if it in control when the file is closed or the program terminates normally. There is a C function fflush(FILE *), but calling it should not be necessary in a Fortran program and adding a call to it may not help if the program is terminating abnormally.

"protect_parens" is a suboption of /assume:,,...

You can add /assume:protect_parens to the IFORT command line, or specify the suboption in one of many ways, as is the case for any compiler option, depending on how you build.

[TimP]

If you are going to terminate your program "unexpectedly," you should close the buffered files first. The flushing should be automatic if the program completes by reaching END.
/assume:protect_parens is important enough that VS users might wonder why they have to enter it in the additional command line options.
protect_parens is included (along with byterecl) in /standard-semantics. Unfortunately, not all of standard-semantics can be recommended unequivocally; noold_maxminloc prevents optimization of those intrinsics, and there may still be reasons for not making realloc_lhs a default.

[dondilworth]

"in one of many ways..." only begs the question. In the Properties dialog, where do I click? Nothing looks like that option. I obviously don't know any of the many ways! I cannot directly edit the command line in that dialog.

I do not find "assume" or "protect_parens" in the help file. What, exactly, is it?

[Les_Neilson]

In Visual Studio from Project -> Properties -> Fortran -> Command Line
in the "Additional Options" box you can add the command line option /assume:protect_parens and any other command line option you may need.

Les