david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (02/13/91)
I recently was forwarded these comments: > > > How can I reduce the size of my X11R3 (Motif 1.0) programs. > > > I converted a simple data entry appliction to Motif and the size > > > of the code went from 200K to 1.3Meg. Thus Motif added 1.1Meg to my code! > > > > The problem is not in your code. Well not really. The problem is that you > > are using UIL. Because a program written with UIL doesn't know which > > widgets it's using at compile time, when you link your program, all the > > possible widgets are linked in. > > > > If you had written your program without using UIL and Mrm, then when you > > linked, it would only link in the widgets that you actually use. This > > should cause about a 200-500K increase, not the usual 1.1M. In truth, you *always* get virtually *all* of Motif if you use *any* of Motif. I assert that there is simply no way to get only 200-500K sized statically bound Motif programs. If you do "Hello World" with just a push button you get virtually everything. Therefore, you pay very little for using UIL or Wcl or any other scheme which references all Widgets instead of just some of them. The real solution is to use shared libraries! On a Sun4, using static binding, we get these sizes for a "Hello World" Wcl program which links in the following widgets: Only PushB 942080 PushB & RowCol 942080 PushB, RowCol, & Text 1155072 Everything 1400832 You just are not going to get much savings for all the pain you inflict upon yourself. If you use shared libraries, you get: Only PushB 24576 Everything 32768 ------------------------------------------------------------------------- David Smyth david@jpl-devvax.jpl.nasa.gov Senior Software Engineer, seismo!cit-vax!jpl-devvax!david X and Object Guru. (818)393-0983 Jet Propulsion Lab, M/S 230-103, 4800 Oak Grove Drive, Pasadena, CA 91109 ------------------------------------------------------------------------- "There was a time when man would attribute everything he didn't understand to God. Now, with our heightened understanding of science, we attribute them to UFO's." -Gary Friedman -------------------------------------------------------------------------
kit@ics.COM (02/27/91)
> > > How can I reduce the size of my X11R3 (Motif 1.0) programs. > > > I converted a simple data entry appliction to Motif and the size > > > of the code went from 200K to 1.3Meg. Thus Motif added 1.1Meg to my code! > In truth, you *always* get virtually *all* of Motif if you use *any* of > Motif. I assert that there is simply no way to get only 200-500K sized > statically bound Motif programs. If you do "Hello World" with just a > push button you get virtually everything. Actually the fault lies in the fundamental architecture of MOTIF(tm). There are many cases in this widget set where a widget's behavior changes depending on who its parent is. For example, the BulletinBoard widget has a resource called "autoUnmanage" which has the following properties. XmNautoUnmanage Controls whether or not BulletinBoard is automatically unmanaged after a button is activated. If this resource is True on initialization and if the BulletinBoard's parent is a DialogShell... Don't ask me why this resource is not on the Dialog Shell, It seems rather broken to me. In any case this part of the specification has the effect of forcing the Bulletin Board's implementation to test whether or not its parent is a Dialog Shell. In order to do this it has to have the Dialog Shell linked into the application, so whether or not you are using a dialog shell you have to load in the code whenever you use a Bullentin Board (or any of its subclasses) There are also cases where the MOTIF Manager widgets special case their behavior depending upon the children that are in them. For example the Bulletin Board had the ability to hard code the font for all its Label and Label Gadget children. Unless that same resource was hard coded on the Label. In any case there is code in the Bulletin Board to implement this functionality that checks each of its children to see if it is a subclass of Label or Label Gadget then sets overrides the font with the BBoard's font. But remember that the only way to determine if something is of a specific class is to check the widget against some information stored in the class. And that means, You guessed it, that widget must be linked into that application. There are other special features of the Bulletin Board that only work on certain children. The net effect of this is that the BulletinBoard widget must statically link in the following widgets. Label, LabelGadget, PushButton, PushButtonGadget, ToggleButton, ToggleButtonGadget, DrawnButton, DialogShell, VendorShell, Text, and List. These are fundamental architectural problems. The issue of static loading is a problem, but as David pointed out this can be alleviated by dynamic linking. What is really frightening is the amount of special case code needed in MOTIF(tm) to allow all these widgets to work together. How will this widget set deal with widgets that it has never seen. Only when more and more custom widgets appear, will finally begin to see all the effects that such a closed architecture will have. Chris D. Peterson Integrated Computer Solutions, Inc. Net: kit@ics.com Phone: (617) 621 - 0060 Address: 201 Broadway, Cambridge, MA 02139