i'm guessing the problem with timing msgs and running
in ui mode is that when you close the connection to the exec
the ui begins shutting down things about the connection
and by the time the exec spews out all the timing info
i think the UI isn't interested in putting it up on the
message window. or the problem could also be that
the messages aren't correctly labeled to show up on the
message window (there's a "message type" flag which comes
with each message from the exec). either way, greg's suggestion
is better with the UI because the timing is printed when you
turn the timer off and you aren't disconnecting from the exec.
makes the '-timing on' flag not very useful except in script mode
i guess.
the problem with the buffer filling up with other timing info
other than module entry & exit points is unfortunate.
there are lots of flags for selecting which debugging/trace
info to print, but i think timing is either on or off and there
are only 2 timing routines - a global timer and a per/processor
local timer for parallel sections. any code which calls the
"mark this time" routine uses up a slot. it would be useful to
implement some sort of selection for which timers actually
are recorded, something like the trace messages.
n.
Randall Hopper wrote:
> nancy collins:
> |yes, "-timing on". i think it doesn't print anything until the exec
> |exits so it's most useful in script mode.
>
> Oddly, -timing on doesn't seem to do anything when running the network in
> dxui. But I tried this in script mode, and it appears this is the
> equivalent to Greg's:
>
> Trace("time",1) -> execute -> Trace("time",0)
>
> in dxui.
>
> Thanks,
>
> Randy
>
> --
> Randall Hopper (mailto:[EMAIL PROTECTED])
> Lockheed Martin Operation Support
> EPA Scientific Visualization Center
> US EPA N127-01; RTP, NC 27711
