v9.10 32bit- long run times with DA files in latest salflibc

We're having a strange problem with a program running much slower with the latest salflibc.

I can find no Fortran reason for a long standing program to run substantially slower than before - a run that in earlier compilations takes a minute to run, now takes 20 minutes to complete. However my colleague (the author of the original code) compiles erstwhile the same program on an earlier version of Silverfrost, so I randomly tried running the executables with the salflibc contemporary with his older compiler.

If we refer to my work as New compiler (v9.10) and the dll provided with that compiler as New salflibc - and similarly Old for the pair of items, we get the following run times, (running the same test on the same machine).

Version New compiler Old Compiler New salflibic 24.27 mins 26.04.mins Old salflibic 1.12 mins 1.11 mins

So the problem appears to be associated with the new salflibc?

The only remarkable feature about the program in the erea where the delay accumulates that it is using a SCRATCH DIRECT ACCESS FILE.

[I know I used to avoid such files 45 years ago on IBM 370 mainframes, as they were slow - every record generating an 'exception' to be handled - but this is the first time I've seen a similar phenomena under Windows}

Can you check whether something has changed in the salflibc etc...

David Swain

I doubt that there has been any related change to salflibc.dll. Are you using the same version of Windows? You could test by copying the DLL (after creating a backup). Versions of salflibc.dll are sometimes interchangeable. 9

Paul - that's exactly what I have done - same machine, same operating system (23H2) - same executables, just changed salflibc. - David

David

There has been a change in order to provide for access to records with size greater than 2GB. I can't see that it would affect your code but if you can send me a working sample then I will aim to investigate further.

Paul

Thanks. Would current executable and input data initially suffice? Because it's a scratch file and deep inside the code, not easy to quickly generate a simple realistic example?

David

I would need the code in order to step through it a then see how it uses the library.

OK - it might go a little quiet from my end while I sort out what I can send.

The fix for the short term seems to package in the older salflibc.dll with our programs, which reduces the immediate pressures on me.

Just a side note: I found that McAfee Anti-Virus would 'get in the way' of FTN95 executables. This began occurred last year. I had to turn off executable scanning. One of the AV processes would start consuming enough CPU to hang up 2 processors for up to 3 hours, sometimes more, unless manually terminated. It was bizarre. I could repeat it on a different machine as well.

I turned it back on with the latest version (9.14) because whatever was causing the bad interaction was no longer present.

FWIW, I can actually see the AV software slowing down my rebuilds as it examines each executable (and DLL) each time a program is run in my MAKE file (i.e. FTN95, SLINK, ...).

Here's the message I sent my users in September 2024. It addresses two 'occurrences' that may or may not be related.

Just a heads up or two, with no release scheduled for it yet.

Heads up 1: I've run across a software solution to generating KMZ files directly within C-Master that (so far) appears to work well. The batch processing is kind of problematic from time to time (i.e. fussy and subject to 'crashing').

Heads up 2: Just an FYI for those who use McAfee anti-virus. I found that McAfee was getting 'hung up' in scanning some file (I don't know which one). It took a few to some 10's of minutes for it to 'release'. What happens is I would start C-Master and see the CPU usage go way up. If I exited C-Master and started it immediately, the CPU usage would take another jump. If I continued this, I could basically overload the computer until these processes stopped.

I mention this because I had to turn off real-time scanning in McAfee. This is not ideal, as it cannot now look for bad files or programs that might be malicious. That said, if you run McAfee and experience this, the remedy is available.

If it is a virus checker issue (McAfee or other) then we would not be able to fix it. It would be an issue for the provider of the virus checker.

Just so we are not distracted by the 'side-note', the Direct Access run time issue is not a McAfee Anti-Virus problem - David****

Can a minimal working example be provided which demonstrates the problem ?

It would be useful to provide some statistics, such as record size and number of records. An invalid record size ( that can be handled differently with different compiler versions) can often be the cause of this type of problem.

Converting to stream access can provide improved functionality and overcome some of these performance problems.

David, agree! It can, however, affect the run-time performance, as it did for me.