RM> A profiler would be closely related to the compiler, in the same
RM> way that a source level debugger is. The profiler needs to be able
RM> to relate lines of source code to lumps of executable code in order
RM> to give you a usable interface (unless you like working at assembly
RM> language level...). As it compiles the source, the compiler has to
RM> provide some sort of "map" for the profiler to read.

Perhaps it would be a good idea to write a "generic" MSDOS
profiler that told you what assembler instructions were being
executed the most, with output being a text file, and then
that way people like me who don't know how to write a profiler,
but do know how to take in two text files, and do some magic
on them, could write that bit?

That would solve the problem for people who were happy with
"sampling" profiling, but not people who wanted to know
elapsed time including system calls?

I wonder how much work would be involved in writing a "sampler"
program anyway?  Especially considering that the scenario is
more likely to be gobs of memory, gobs of disk space, gobs of
CPU, trying to profile some small DOS application, so you can
do silly things like write out gobs and gobs of profiling info.

BFN.  Paul.

P.S. I see from another message that Kieran says that TCPROF
only works for TC 2.0 and prior.  Perhaps a program that
converts TC++ map files into TC 2.0 map files is what is needed?

P.P.S. I am not happy with Watcom's profiler.  From what SMALL
amount of evidence I have seen, the pecking order of profilers
under OS/2 goes:

VisualAge C++
CSET
Watcom.

You might want to consider VisualAge C++ as one of the compilers
to check out, assuming they have a DOS compiler too.
@EOT:

---