forums.silverfrost.com

[JohnCampbell]

I have just found the /timing option in FTN95 and used it for two of my larger projects, with very good success. Having for years tried to monitor program performance, by including timing check calls and accumulations, the ease of use of /timing was a surprise. Based on past experience, I grouped all .f95 program files I wanted to monitor into a single file, using INCLUDE's, producing a large .obj and then linked and ran. The results were very easy to obtain, with no change to the original source code. This is in a win32 environment. One program has 360 routines and the other 380.

I would recommend this feature to others, as it has worked for me with good results.

A suggestion on the output; most reports need further analysis, so the reporting as a space delimited or tab delimited format would help for import into excel. The present reporting of long routine names makes this a little messy.

Thanks for the easy profiler.

Regards

John Campbell

[Andrew]

There is something like this already in the timing mechanism. To use this you need to make use of an environment variable TIMINGOPTS. To enable spreadsheet compatible output you should specify /TMO as a value for the environment var. It is also possible to specifiy a separator character using /DLM <char> in the variable too. The output is dumped to a file with the extension .tmo. The information is not quite as detailed as that in the .tmr file, but is still very useful. An example of the environment variable could be:

set TIMINGOPTS=/TMO /DLM ,

Which would produce a .tmo file containing data separated by commas.

[JohnCampbell]

Andrew,

Thank you for your reply.
I tried the set TIMINGOPTS=... before running the program. The resulting .tmo gave what I needed.
At which version was this option added to FTN95 and is there any further documentation of these features ?

Regards John

[PaulLaidler]

John

A /TIMING option has been available with FTN95 since at least version 2.0.

I assume that you have seen the documentation in the current help file (FTN95.chm, search for TIMING). This is quite comprehensive. The only undocumentated option (in addition to /DLM and /TMO) is /NAME. This allows you to specify the name of the report file.

[sparge]

I just tried this feature for the first time this morning, using Plato and Win32, prompting two questions:

1) I can't get .TMO output. The documentation talks about two options - Visual Studio and .NET (where TMO is provided by default), and command line (where an environment variable needs to be set to get it). I tried setting the environment variable as per documentation but it did not work. Please can Plato be made "TMO-aware" too?

2) According to the TMR output, the main program is called twice - an unexpected finding to say the least . Can someone explain what is going on here?

Andy

[JohnCampbell]

Andy,

I can't explain your 2 calls to main.
A couple of ideas from my earlier use of /timing in March this year, which was quite successful.
I was working in a win32 environment and not .net.
My main program did not have a program statement, so my MAIN@ appears (with 1 call) in the list.
I collected all files for the program, including some library source files, and assembled them all as a single .f95 file being a list of include statements. This list is the list of all routines that I wanted to time. This may not be necessary but it was a requirement of past profiling utilities and it does not cause any problems. I excluded some (extremely frequently called) routines from this list in util.f95, so they would not be timed.

I then compiled the program using the following:
ftn95 sim_ver1_tim /timing >ftn95.tce
ftn95 util /debug >>ftn95.tce
slink main_tim.txt >>ftn95.tce

where main_tim.txt is:
lo sim_ver1_tim.obj
lo util.obj
le clearwinsaplib.memsaplib.lib
map sim_tim.map
file sim_tim.exe

I then ran sim_tim.exe and got the list that I wanted. The program terminated normally, which is necessary to get the report.

To obtain the excel type output, I used the set parameter option, as Andrew indicated:
set TIMINGOPTS=/TMO /DLM ,
I then compiled and ran the program, and again got what I wanted. ( I do not have a batch file of doing all this, but my forum response indicated it worked)

The file sim_ver1_tim.f95 consists of:
include 'sim_data.f95'
include 'yrdplt.f95'
include 'sim_ver1.f95'
include 'read_data.f95'
include 'open.f95'
include 'stem_gen.f95'
include 'next.f95'
include 'day.f95'
include 'vessel.f95'
include 'tide.f95'
include 'train.f95'
include 'train_move.f95'
include 'pend.f95'
include 'choose.f95'
include 'pform.f95'
include 'update.f95'
include 'report.f95'
include 'lotus.f95'

In this example, sim_data.f95 and yrdplt.f95 contain module definitions, while sim_ver1.f95 is the program start.
util.f95 and the library files consisted of all routines I did not want timed. The results can vary substantially by what frequently called routines are excluded from the timing list, as there is a bit of an overhead for each routine that is timed. Some of my routines can get up to 10^9 calls, so it's good to exclude them from the timing.
This /timing approach is far easier than my past manual efforts of putting timing calls in the code. /timing is not an option I use every day, but it is useful and easy to apply in this way, when needed.

I hope these comments help, as I found this approach very easy to apply, with no impact on the fortran code.