john@quonset.cfht.hawaii.edu (John Kerr) (08/15/90)
Are there any general hints for speeding up a Motif application? For
instance, does eliminating the resource file and hard-coding the
resources make for faster startup and execution?
I realize the cpu and server implementation are a factor, but what
might be some good rules to follow when coding the application.
BTW, we are running HPUX on HP9000/300 series computers. We have the
latest X server from HP and are running Motif 1.0.
Thanks,
jk
----------------------------------------------------------------------------
John Kerr Canada-France-Hawaii Telescope Corp.
INTERNET: john@cfht.hawaii.edu
BITNET: john@uhcfht
----------------------------------------------------------------------------steve@acorn.co.uk (Steve "daffy" Hunt) (08/15/90)
In article <9007@uhccux.uhcc.Hawaii.Edu> john@quonset.cfht.hawaii.edu (John Kerr) writes: >Are there any general hints for speeding up a Motif application? For >instance, does eliminating the resource file and hard-coding the >resources make for faster startup and execution? If you are using UIL, do some tests to see how much of the application startup time is spent in UIL/Mrm activities. On the 1.0.A system I have been using, the UIL/Mrm stuff that happens at application start has a large detrimental effect on the startup time. I hope this has been improved in 1.1! -- Steve Hunt steve@acorn.co.uk
argv@turnpike.Eng.Sun.COM (Dan Heller) (08/16/90)
In article <9007@uhccux.uhcc.Hawaii.Edu> john@quonset.cfht.hawaii.edu (John Kerr) writes: > Are there any general hints for speeding up a Motif application? For > instance, does eliminating the resource file and hard-coding the > resources make for faster startup and execution? You should be very careful about this decision -- from the user's point of view, many resources should be configurable and you should not hard-code values. The _general rule of thumb_ is: hardcode as few resources as possible. *however* it is perfectly reasonable to hardcode many values and it is not uncommon to do so. You just need to be aware of each one and ask yourself, is it reasonable to expect the user to modify this resource himself? The answer to your question, on the other hand, is simple. You are not going to improve performance or provide any other optimizations by hardcoding values. Performance of motif applications seems to be in the utilization of resources and widgets. That is, allocating and freeing large blocks of memory takes time -- anything that you do *repeatedly* will affect performance. Converting between text and XmString's can be expensive if you do it frequently (hint: cache as much as possible). Also, some actions seem like they perform reasonably in small-scale situations (e.g., short lists for list widget or short text for text widgets), but suddenly performance goes down the drain when your lists or texts suddenly become large. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
david@ics.com (David B. Lewis) (08/16/90)
In article <1990Aug15.221852.5493@ics.com>, nazgul@alphalpha.com (Kee Hinckley) writes: |> In article <9007@uhccux.uhcc.Hawaii.Edu> |> john@quonset.cfht.hawaii.edu (John Kerr) writes: |> > |> >Are there any general hints for speeding up a Motif application? For |> >instance, does eliminating the resource file and hard-coding the |> >resources make for faster startup and execution? |> |> I have heard that Frame ended up putting resources for each |> dialog box and window in a separate file and loading them on |> demand. I'm not sure why they didn't just hard code them, but |> my impression is that yes, resources can be costly for large |> applications. Most are wild-carded (e.g. all shadowThickness of all XmDialogShell is 1), so the total set of resources is not large. Note that this wins for them when porting to other platforms. -- David B. Lewis david@ics.com david%ics.UUCP@bu.edu ...!uunet!ics.com!david "Then again, it could have been the little purple feet." -- Sun
nazgul@alphalpha.com (Kee Hinckley) (08/16/90)
> Most are wild-carded (e.g. all shadowThickness of all XmDialogShell is > 1), > so the total set of resources is not large. This is actually a more general Intrinsics question, but I might as well start here. Is there any way to create a wildcard resource from within my application (e.g. at application startup add "*foreground: polkadot")? Secondly, is there anyway for my application to check and see if a particular resource has been defined, so that it can set the resource only if the user has not? -kee Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -------
richard@unipalm.co.uk (Richard) (08/16/90)
> Are there any general hints for speeding up a Motif application? For > instance, does eliminating the resource file and hard-coding the > resources make for faster startup and execution? The biggest improvement you can make in my experieence is not to use UIL. The first time a UIL-defined widget tree is mapped there is a significant time delay which is unacceptable for some things like popup menus. This may be improved in 1.1, but in 1.0 it was trully awful. Richard Nuttall richard@xtech.uucp XTech, Cambridge, England ukc!acorn!unipalm!xtech!richard Tel: +44 954 211862 richard@unipalm.uucp
jollyc@HPWARF.HP.COM (Jolly Chen) (08/16/90)
> This is actually a more general Intrinsics question, but I might > as well start here. Is there any way to create a wildcard > resource from within my application (e.g. at application startup > add "*foreground: polkadot")? Secondly, is there anyway for > my application to check and see if a particular resource has > been defined, so that it can set the resource only if the user > has not? Check out the Xrm calls in Xlib. For example, XrmPutStringResource() allows you to add a resource spec. Either instance name or class may be used, and they may be bound with loose (*) or tight (.) bindings. There are also more general routines like XrmGetResource() and XrmPutResource() as well as quark versions, i.e. XrmQGetResource(), XrmQPutResource(), etc. You can even do stuff like get a search list from the resource database and search only that list; see XrmQGetSearchResource() and XrmQSetSearchList(). (Gee, I didn't even know you could do that until I flipped a few more pages in the reference manual just now.) - Jolly Jolly Chen Clinical Information Systems Hewlett-Packard Waltham, MA jollyc@hpwarf.hp.com
wex@dali.pws.bull.com (Buckaroo Banzai) (08/16/90)
One thing you can do to vastly speed up your use of resource files is eliminate wildcards. This is particularly true with respect to fonts. With one of our programs we were able to get a 7-10x increase in startup speed simply by getting rid of all wildcards in all font names. Sacrifices portability, of course, but if you know the font's going to be present... -- --Alan Wexelblat phone: (508)294-7485 Bull Worldwide Information Systems internet: wex@pws.bull.com "Politics is Comedy plus Pretense."
ron@xwind.UUCP (Ronald P. Hughes) (08/17/90)
In article <9007@uhccux.uhcc.Hawaii.Edu> john@quonset.cfht.hawaii.edu (John Kerr) writes: >Are there any general hints for speeding up a Motif application? For >instance, does eliminating the resource file and hard-coding the >resources make for faster startup and execution? > ... >BTW, we are running HPUX on HP9000/300 series computers. We have the >latest X server from HP and are running Motif 1.0. Some machines (yours included) have an alternate malloc library available. If you use it you may see your application run twice as fast (no kidding). With some of the older versions of malloc, all allocated blocks remained linked in a single linear linked list. Each time a new block is allocated, all previously-allocated blocks are checked to see if they are now free and big enough to satisfy the request. X, and the intrinsics, and Motif, all allocate lots and lots and Lots and LOTS of little chunks of memory. Not only does that make the list very long, but think of how it affects paging performance to fondle 98% of your data pages every other millisecond! A/UX also suffers from an old malloc (although their alternate malloc library is buggy). Sun machines seem to have a decent standard malloc. Ronald P. Hughes ron@xwind.com (or ...!uunet!xwind!ron) CrossWind Technologies, Inc. 408-335-4988 "Malloc: if it was good enough in '77, it's good enough today!"
tsang@isi.com (Kam C. Tsang) (08/17/90)
> Secondly, is there anyway for my application to check and see if a > particular resource has been defined, so that it can set the resource > only if the user has not? Let me cheat and answer only the second question, because I have no clue on the first one. The call is XtGetSubresources: -------------------- start of demo program ------------------------------ #include <Xm/Xm.h> #include <X11/StringDefs.h> #include <X11/Shell.h> typedef struct { } ApplicationData, *ApplicationDataPtr; ApplicationData AppData; #define XtNusername "username" #define XtCUsername "Username" #define XtNdebug "debug" #define XtCDebug "Debug" /* In intrinsic.h: typedef struct _XtResource { String resource_name; // Resource name String resource_class; // Resource class String resource_type; // Representation type desired Cardinal resource_size; // Size in bytes of representation Cardinal resource_offset;// Offset from base to put resource value String default_type; // representation type of specified default caddr_t default_addr; // Address of default resource } XtResource; */ static XtResource resources[] = { { XtNusername, XtCUsername, XmRString, sizeof(String), XtOffset(ApplicationDataPtr, username), XmRString, "Number Johnny Five", }, { XtNdebug, XtCDebug, XtRBoolean, sizeof(Boolean), XtOffset(ApplicationDataPtr, debug), XtRImmediate, (caddr_t) FALSE, } }; /* see page 88 */ /*------------------------------------------------------------- ** main - main logic for application */ void main (argc,argv) unsigned int argc; char **argv; { Display *display; /* Display */ Widget app_shell; /* ApplicationShell */ XtToolkitInitialize(); display = XtOpenDisplay (NULL, NULL, argv[0], "XMdemos", NULL, 0, &argc, argv); if (!display) { XtWarning ("xfonts: Can't open display, exiting..."); exit (0); } app_shell = XtAppCreateShell (argv[0], "XMdemos", applicationShellWidgetClass, display, NULL, 0); XtGetSubresources(app_shell, &AppData, "Bboard.Label", "bboard.label", /* extra for XtGetSubresources */ resources, XtNumber(resources), NULL, 0); printf("width: %d\n", AppData.width); printf("height: %d\n", AppData.height); } -------------------- end of demo program ------------------------------ -kam -------------------------------------------------------------- Kam Tsang User Interface Group Tel: (408) 980-1500 x275 Integrated Systems, Inc. Internet: tsang@isi.com 2500 Mission College Blvd. Voice mail: (408) 980-1590 x275 Santa Clara, CA 94054
markham@cadence.com (Jeff Markham) (08/17/90)
Yes .. malloc can be a problem .. and if you need a fancier one (in case your vendor doesn't have one) the gnu emacs distributions have a pretty neato one .. and one that biased toward the sizes that Xt and Xm create. Jeff Markham markham@cadence.com
thp@westhawk.UUCP ("Timothy H Panton.") (08/21/90)
We found that malloc() was called _very_ often during widget creates (I'm talking about the HP widgets, but I guess the same applies). It is well worth shopping around for a fast malloc. Last time I looked the malloc() in Gnu was about twice the speed of that in libc.a (HPUX 6.5) The other thing that made a big difference to us was creating all a widget's children with XtCreateWidget() and then doing a XtManageChildren on the whole batch. +----------------------------------------------------------------------------+ |Tim Panton, Westhawk Ltd. "... avoiding vain and profane babblings." | |Phone: +44 92822574 -1 Timothy 6:20. | |uucp : ..!mcvax!ukc!westhawk!thp | |Paper: Westhawk Ltd. 26 Rydal Grove, Helsby, Cheshire, WA6 OET. UK. | +----------------------------------------------------------------------------+