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 |
From time-to-time, I am asked whether my group has a Guide to DECWindows Performance which advises programmers on how to write fast DECWindows applications. To my chagrin, the answer is "no". But there are a few Rules Of Thumb which may or may not be obvious. Please feel free to add more ROTs and/or correct the ones listed below... - nothing is obvious; experiment with different algorithms - when you study memory and CPU use, remember that you need to consider not just the application, but the server also - windows, widgets, and GCs are NOT cheap; use them sparingly (counter to the MIT design philosophy) - use gadgets instead of widgets if at all possible - generally, a complex widget is an expensive widget; for example, dialog boxes - be aware of operations that require the window manager to get involved; for example, creating and mapping a window that can be resized or iconified has to go through the window manager - toolkit widgets pay a performance price for being general purpose; consider writing your own special-purpose widget if necessary - if you write your own widget, use the translation manager sparingly - process your incoming events and replies ASAP; don't let them pile up and possibly overflow your transport buffers - avoid XFlush and XSync; that just means you have to pay more to transport less - remember that there are going to be other applications executing; handle Focus properly and avoid Grabs if possible - watch for flickers or sparkles on your screen; you many be drawing the same thing several times John B.
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
1465.1 | QUARK::LIONEL | Free advice is worth every cent | Wed Sep 20 1989 11:48 | 10 | |
I'd also add a admonition to free memory wherever needed. There are just too many places in the toolkit that make it easy to leak memory. The compound string routines are a primary example, but one that some might not think about are the VAX binding argument list building routines (DWT$VMS_SET_ARG, etc.) Unfortunately, the documentation is silent on this - only by stumbling across the description of the routines that do the freeing might you start to have a clue that it is necessary. Steve | |||||
1465.2 | A few more... | LEOVAX::TREGGIARI | Wed Sep 20 1989 13:49 | 14 | |
- Fonts and large pixmaps are expensive; use them sparingly... - Don't create widgets until you need them. For example, at start-up only create the widgets needed by your "main" window. - Call XtSetValues and XtGetValues sparingly. For example, create a widget with all of its resources set properly, rather than create it and then immediately call XtSetValues. Also, use "convienence" routines like DwtToggleButtonGetState instead of XtGetValues, when possible. Leo |