[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

1459.0. "Specific performance questions" by HGOVC::KENBERKUN (People that melt) Tue Sep 19 1989 01:46

    I have some performance related questions.  The application runs on VMS, so
    all the tuning info is black magic to me.  It makes heavy use of ASTs
    and they do lots of xcopyareas to and from pixmaps and windows (emulating
    backing store, having come from the UIS world).
    
    Environment: VMS 5.1b DECwindows 1 SDC versions, VS3100, 8 Meg RAM,
    2 RZ23s, system and pagefile on one, application on the other.
    
    1. Is a pixmap stored in the server or client?  It appears that the
    server is paging heavily.
    
    2. Page faults are very high.  Can someone recommend some tuning
    parameters?  Here are a few select parameters:
    
    	wsdef = 4096, wsquo=9000, wsext=10,000
    	wsmax = 10,000, gblsections=300,gblpages=20700
    
    	I can provide other parameters at request.
    
    3. They tried the application on a 16 Meg system and it ran "faster". I 
    didn't see it, so I can't say how fast, nor do I know the parameters.
    If the only answer is more memory, then I need to tell them why.
    
    The application appears very slow, although I suspect they have other 
    problems as well.  Leading to:
    
    4. They do a lot at AST levels.  Is it reasonable to do a xcopyarea
    from a pixmap to a window, each about decterm size, at the AST level?
    It strikes me as a lot to do.
    
    An example of slowness is how long it takes them to pop up a window
    and write some text in.  It can take several seconds.
    
    Thank you for any help or advice and please let me know if you need
    more information.
    
    Ken B.

T.RTitleUserPersonal
Name
DateLines
1459.1GPX offscreen memorySTAR::BMATTHEWSTue Sep 19 1989 08:5521
Pixmaps are kept in the server. What is probably happening is the sum total
of the pixmaps they are using is more than the available offscreen memory
for a GPX system. GPX has about 1024x864 of offscreen memory for large pixmaps.
If they can get their pixmap(s) down to that size or less it would be a big
win. 1 1024x864 or smaller pixmap should work well as long as there are not
other apps with pixmaps that are also drawing at the same time. When the pixmap
is in offscreen memory then the time to do a XCopyArea is 8mpixels/sec.

They should keep a bounding box is the area drawn since the last XCopyArea if
possible to reduce the number of copies. At least they should keep a flag as
to whether or not there were any draws since the last AST. If there is a
lot of drawing over a large area then they will want to do the XCopyAreas
less frequently to allow more time for the draws. They may want to vary to
XCopyAreas from once every 200 milliseconds to once every 600 milliseconds
when the system is busy.

If there are more pixmaps than GPX offscreen memory then increasing the servers
working set parameters will help. There are logicals that can be set so that
the server gets larger working set parameters. See sys$manager:decw$startserver.com
							Bill

1459.2Depth 1 gives you more alsoDECWIN::FISHERBurns Fisher 381-1466, ZKO3-4/W23Tue Sep 19 1989 20:189
    Also, if they have several pixmaps smaller than 1024x864, and if the
    windows they are backing up with them only contain two colors
    (foreground and background, not two colors + background) then they
    can use depth-1 pixmaps for backing store (using CopyPlane rather than
    CopyArea) and get 8 times as much pixmap storage space.
    
    Burns