home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / vms / 13563 < prev    next >
Encoding:
Text File  |  1992-08-12  |  3.2 KB  |  72 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!gatech!darwin.sura.net!convex!convex!ssimmons
  3. From: ssimmons@convex.com (Steve Simmons)
  4. Subject: >>>>>> PCA gives strange results
  5. Sender: usenet@news.eng.convex.com (news access account)
  6. Message-ID: <ssimmons.713634003@convex.convex.com>
  7. Date: Wed, 12 Aug 1992 15:40:03 GMT
  8. Nntp-Posting-Host: pixel.convex.com
  9. Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
  10. X-Disclaimer: This message was written by a user at CONVEX Computer
  11.               Corp. The opinions expressed are those of the user and
  12.               not necessarily those of CONVEX.
  13. Lines: 57
  14.  
  15.  
  16. Friends,
  17. >         We are currently using PCA (Performance and Coverage Analyser)
  18. > to try to cut down the run time of some in-house analysis code.  The
  19. > results have been a bit strange.  Apparently this program is spending
  20. > roughly 30% of its time executing one or the other of two subroutine
  21. > CALLs (not the subroutines themselves, nor the rather involved (IMSL)
  22. > subroutines called from within the subroutines).  Oh, source language
  23. > is VAX FORTRAN.
  24. >        Am I simply misunderstanding what the results mean, or is there
  25. > possibly something happening to distort the results?  I checked the
  26. > machine code generated for these lines and they're regular old CALLG
  27. > instructions.  Could some other code somewhere be getting counted
  28. > against these lines (I didn't see any code to actually set up the
  29. > argument list, for example)?
  30. >         Since this is probably a case of my not understanding what
  31. > I'm doing properly (*blush*), I've set followups to sender, but
  32. > if this raises any points of interest, please post.
  33.  
  34. Probably, you are using PCA V2.0 or later.  In this case, the default 
  35. behavior for the PLOT command charges the first PC on the stack within 
  36. the MAIN IMAGE's address boundary to the appropriate bucket.  Thus, 
  37. all of the PC samples within IMSL  are charged to the instruction where 
  38. the CALL is made. If this is not desired, use the /NOMAIN_IMAGE qualifier.  
  39.  
  40. In PCA V2.0, there are three stack operators that can be used
  41. with TAB, PLOT, INCLUDE, and SET FILTER.  That is, these operators 
  42. assume the presence of the call chain.  The call chain is walked
  43. to determine which pc on the stack to charge the hit. They are...
  44.  
  45.     - /MAIN_IMAGE[=address boundary]  - This says chose 
  46.       first pc on the stack within the address boundaries.
  47.       This default to the entire image; however, you can provide
  48.       one routine name.  If you want the hotspot within Routine BAR,
  49.           type PLOT/MAIN=BAR ROUTINE BAR BY LINE.     
  50.  
  51.  
  52.     - /STACK_DEPTH=n - Starting from the bottom of the stack, take
  53.       the PC that is "n" frames away.  /MAIN takes precedence. 
  54.       Therefore, PLOT/MAIN=BAR/STACK=1 PROG BY ROUTINE informs 
  55.       the user about which routine calls BAR the most. 
  56.  
  57.         - /CUMULATIVE[=n] - Select the first "n" pcs on the stack. 
  58.       In this case, more than one pc is selected. The default
  59.       is all PCs on the stack.  If the /MAIN and /STACK were
  60.       used, they would take precedence and the starting point
  61.       would be defined by those two operators.  If you only
  62.       want to see those PCs where FOO calls BAR, just type..
  63.  
  64.        SET FILTER F1 PROGRAM=FOO/CUM/MAIN=BAR
  65.  
  66. Does this answer your question??? ;-)
  67.  
  68. Thank you. 
  69.  
  70.                     Steve Simmons
  71.  
  72.