Re: LEN_TRIM performance issue

Gordon Sande <g.sande@xxxxxxxxxxxxxxxx> wrote:
(someone wrote)

Herre's a follow up question. gprof seems unable to determine the
"parent" or "child" function of built-in functions such as LEN_TRIM.
Thus, the call graph does not tell me which LEN_TRIM statement is the
major culprit. Does this info about the call graph help to explain
this?
(snip)

Profiling has the problem of not knowing how to assign work back up the
call nesting list. A long time ago in a Fortran 66 execution profiler
I had such a capability. But it relied on instrumenting the code and
compiling the instrumented code. It was then able to know when routines
were entered and exited. With that information one could report both the
work done locally and all the work between the enter and the exit. That
facility became known as the "Bell profiler" as many folks first saw it
in action at the Murray Hills site of Bell Labs. As an instrumenter it
was capable of exact line counts as well as timing. A synthetic "clock"
of the "Fortran machine" which matched the exact line counts was often
as useful as the timings. The timer had considerable overhead so tended
to distort the times for low level utilities.

One I used to use a long time ago (before I had programs that needed
it) was called FETE, Fortran Execution Time Estimator. I tried to
find if any copies still exist, but instead found someone with a
different, but similar, program.

FETE would read the source program, and write another program
out to be input to the compiler. The compiler option for printing
the source program and error messages was turned off, so it helps
not to have any compilation errors. The compiled program then runs,
counting how many times each statement is executed, how often a logical
IF is true, and an estimate of the time to execute that statement.

At the end, the compiled program prints out a source listing with
three numbers after each statement, as described above.

That was for Fortran 66, or at least IBM's extensions to it.
(It probably needed at least END= on the READ statement.)

If anyone knows where a copy, machine readable or not, still exists,
I would be interested to know about it.

-- glen


The notion of instrumenting and line counting was copied from a Knuth
student, Don Ingalls. That tool had poor reporting and did not try to
look at timing or the problems of call nesting. There was an F77 execution
profiler as part of the SoftTools (NAGTools?). I believe that plusFORT(?)
has a similar capability. I have never seen enough detail on either to
know how they deal with call nesting.

Most "profilers" seem to be location counter samplers that rely on load
maps. Figuring out a call nesting would be a lot of work so it not done.
The advantage is that they do not need to know about which language is
involved as they are basically assembly driven. Sampling has its own
set of problems. Location counter samplers have lots of benefits but
calling them "profilers" has managed to lose/hide a lot of what the true
profilers can do.



.

Relevant Pages