GT.M already has code profiling
Posted by K.S. Bhaskar on 2009-05-04 00:57
GT.M has a good profiling capability. If you do something like:
Set TraceStamp=$J_","_$H
View TRACE:1:^TRACES(TraceStamp)
... execute code to be traced ...
View TRACE:0:^TRACES(TraceStamp)
Then dump ^TRACES(TraceStamp), you will get data for a code histogram. You can also put the trace information in a local variable, in case you don't want to save it past process exit.
Our Profile programmers also used the trace capability to come up with a great tool to study test coverage and find code that is not exercised by automated tests (which can suggest the need for additional test cases, or perhaps a better compiler optimization, or perhaps unnecessary
application logic). But this is not part of GT.M or PIP.
Note that the histogram is useful, but the time stamps are always zero. This is because on any PC today, any line of M code executes in well under a microsecond, the resolution of a POSIX timer.
Regards
-- Bhaskar
Set TraceStamp=$J_","_$H
View TRACE:1:^TRACES(TraceStamp)
... execute code to be traced ...
View TRACE:0:^TRACES(TraceStamp)
Then dump ^TRACES(TraceStamp), you will get data for a code histogram. You can also put the trace information in a local variable, in case you don't want to save it past process exit.
Our Profile programmers also used the trace capability to come up with a great tool to study test coverage and find code that is not exercised by automated tests (which can suggest the need for additional test cases, or perhaps a better compiler optimization, or perhaps unnecessary
application logic). But this is not part of GT.M or PIP.
Note that the histogram is useful, but the time stamps are always zero. This is because on any PC today, any line of M code executes in well under a microsecond, the resolution of a POSIX timer.
Regards
-- Bhaskar
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Atmus is powered by Assembla.
1 Comments
By alexwoodhead on 2009-05-04 11:32
Found more details in the GTM programmers guide page 212.
So the proposed profile tool would still be useful for code coverage provided by unit tests.
Also it seems profiling tends to be done by process ($Job). This is fine for terminal type applications where a user is tied to a single mumps process. However it would also be useful to be able to profile by session context.
For example:
A user of a web application may have their pages served by many different mumps processes over the span of a web session.
It would be nice to have a consistent session view of profile and code coverage.
Maybe it would be useful to have a "profile" flag on a user web application account so when the web user is logged in, all their activity is profiled?