PE> Since it does neither, all I can say is that I don't trust Watcom's
 PE> profiler as far as I can throw it, and will stick to using CSET

Watcom's profiler works by interrupting the program very rapidly,  and
seeing where cs:ip is.  This is a popular profiling method,  not not very
accurate unless the interrupt period is _very_ small -- such a small period
is not realistic with OS/2's DosDebug() api.

I complained about this to Watcom a long time ago,  and they said they were
working on a solution more like IBM's.  I do not know if this made it into
10.5 (I won't upgrade).

Some advantages to this technique are:

 - Can be used without the compilers involvement
 - Is not based on the function (so you can  break down the results
   to a line or instruction level)


IBM's profiler works with the compiler -- the compiler inserts special
calls to the profiler library;  the library is able to keep accurate counts
on the number of times a function is entered,  and how long it took (if it
can accurately remove the profiling call overhead,  which is easy)).  This
does not require the program to be interrupted -- so is much more efficient
under OS/2 (but,  perhaps,   not other OS's).

 Advantages:
  - Accurate.
  - Fast (under OS/2)

Disadvantages:
  - Can't break it down past the function level (unless a way is provided
    to cause profile events inside a function -- Cset provides some sort
    of thing for this,  but I have not tried it and am not sure if it
    just records the "user event", or if it actually makes an impact on
    the statistics).
  - The program must be compiled in a special way.


Someday (hopefully) IBM or Watcom will combine the two techniques to create
a truly useful profiler.

ps: VA C++ 3.0 will allow you to see the function (by loading the
editor),but does not break the profile down any further.


--- Maximus/2 3.00