  Determining Application Performance Bottleneck? 
 The Question is:
 
I recently asked some questions about memory residence and DECram. I've since
 learned more. What we want is to reduce the time it takes to load some
 graphics files by a third party XWindows graphics app. that we use. I tried
 DECram. I also tried global bu
ffers and running 2 instances of the app. But neither approach helped. I tested
 by alternating repetitively between opening the same 2 large graphics files in
 the app. The first open of the files takes a little longer while the process
 adjusts working set
 and virtual address space. But subsequent opens are almost as slow despite the
 process showing no page faults (I allowed the app an usual large working set).
 So I figure there is no need to pursue memory residence, DECram or DCL
 INSTALL. A "show proc /co
nt" showed that the loading is very CPU bound. It also showed a lot of direct
 and buffered I/O in a ratio of 2:1. But no page faults. I ran the app. from
 the console thereby using the local transport. Is there a way to get a
 distribution of the CPU time s
pent in the images, modules and functions executed by the process in order to
 figure out where to optimize code? The app. is single threaded. The Alpha is a
 DS20, 1 Gb, 1 processor. Would adding another processor board help? Is there a
 way to save, swap a
nd reload the address space of the process thereby reducing the reload of the
 files to a memory copy of already loaded files? Bumping the Mhz does not
 appear to be an option. Would a faster graphics board be an option? How can I
 tell the time spent by the
 CPU on waiting for the graphics card? Are wait cycles for a slow graphics card
 counted as CPU time? We could of course use a process and a window per
 graphics. But we trying to avoid that. Any suggestions are much appreciated.
Thank you very much.
 
 The Answer is:
 
  The vendor will need to review the program activity, potentially working
  with the Customer Support Center and OpenVMS Engineering and/or DECwindows
  Engineering to determine the particular performance bottleneck involved.
 
