Conference bulova::decw_jan-89_to_nov-90

There is no table that I know of.  Here are some "rough" numbers (from memory)...

 o  average gadget takes ~200 bytes

 o  average widget takes ~400 bytes

 o  text widget takes ~600 bytes 

 o  widgets that create their own internal children (or shell parent) take more
    (sum of the widgets) (e.g. file selection, caution box...)

These are the "per instance" dynamic memory cost.  Each widget class also
has a 1-time class cost .

Leo

Leo,

this is very useful information.   Thanks to Olav for asking the question.

Next Point:

I am assuming that this data is derived from a CISC system (VAX)....

Is it silly for me to add 30% to 45% more memory over-heads to Leo's data,
for a RISC system - assuming that code density differences between CISC
and RISC will put me in that ball-park?

I am aware that the big caches in a RISC machine will offset some of the
memory bandwith overheads caused by the huge DECwindows executables.

thanx for any answers,

Kris..

> I am assuming that this data is derived from a CISC system (VAX)....

    Yes.
    
> Is it silly for me to add 30% to 45% more memory over-heads to Leo's data,
> for a RISC system - assuming that code density differences between CISC
> and RISC will put me in that ball-park?
    
    The two things that I can think of that would make these numbers larger 
    would be if the C compiler did not densely pack its data structures (e.g.
    put all instance data fields on natural alignment boundaries) or if the
    size of an address was larger (e.g. 64 bits).
    
    Of course, the toolkit code would get larger on a RISC machine.
    The V1 toolkit code on a VAX is about 450K.
    
    Leo

    One more consideration is the server-side memory used by the windows
    that correspond to realized widgets. Presumably the figures in .1 don't
    include this?
    
    Also it's interesting that the V1 toolkit code on a VAX is 450k yet on
    Ultrix (VAX) /usr/lib/libdwt.a is 900k. Is this perhaps an inefficiency
    of the Ultrix object format? On VMS decw$dwtlibshr.exe is only a little
    over 1000 blocks, which is a reasonable overhead to hold 450K of code.

Archives need to contain symbols, so they will will be larger than what you
would expect from looking at the text size.  The symbols get stripped out
of the executables, and the program text and data is all that's left.
				Jeff

The symbol table for the PMAX looks even more 'outrageuos' :-)

Kris..

    Re .6:

    Yes... We were absolutely blown away when we saw Calendar running on
    the PMAX (with no local disks...), and we haven't recovered yet! You
    really discover a new world of computing! Things like context
    sensitive, switching views etc... Just amazing, when you consider that
    the PMAX processor doesn't get any help at all from the hardware for
    graphics et all.

    Denis.

>    One more consideration is the server-side memory used by the windows
>    that correspond to realized widgets. Presumably the figures in .1 don't
>    include this?
    
    Yes, those numbers were client side only.
    
    Leo
    

    Adding another question to the discussion (courtesy of inexperienced
    customer and unspecific DECUS symposium rumor <*sigh*>).
    
    Situation: trying to size a remote client node using ULTRIX &
    DECwindows.  Application is brand-new, as yet in functional-spec
    phase, and will serve a home-brew database to between 30 and 100 users.
    
    This customer is very concerned about the size of DRM and wants to
    know:
    
    (A) How much "extra" memory on the client is burned by using DRM calls 
    to open and read UID files?  Customer is interested in approximate size
    of code.  Evidently the word he got from DECUS was LOTS, and that on
    ULTRIX, it's not shared...
    
    (B) Is there any other per-user cost that ought to make a significant
    difference in how the client node is sized or configured [DISKs...?]?  
    Obviously the application will be doing other things beside pushing 
    widgets around, but the customer is concerned that the per-process cost 
    of DECwindows code/data on the client might be the driving factor...
    
    (C) When UID stuff is replaced with Xt or Dwt calls, does that
    significantly effect the per-process size?
    
    Please forgive these novice questions, I'm neither experienced at
    ULTRIX or DECwindows.  Any advice or assistence would be greatly
    appreciated.
    		      		Brian Beattie

>    (A) How much "extra" memory on the client is burned by using DRM calls 
>    to open and read UID files?  Customer is interested in approximate size
>    of code.  Evidently the word he got from DECUS was LOTS, and that on
>    ULTRIX, it's not shared...

Yes, there is lots of code and data, but DRM is not an overwhelming part of
it.  Xlib and Dwtlib together account for almost 750K of code and static
data.  DRM is about 50K of that.  Note also, that the include files as
shipped will always bring DRM into the image.  So, you would not only have
to not call DRM, but also modify the include files to not have DRM included
in the image.

As far as run-time overhead goes, you basically have 3 options:

1.  Use DRM -  it allocates 32K of buffers to read in the UID file
    information.  But, other than that, it is very good about freeing
    dynamic memory that is not needed.  I would "guesstimate" that it also
    adds ~10% cpu overhead to widget creation.

2.  Use XRM (i.e. put strings, x and y locations, etc... into xdefaults
    files) -  reads the entire xdefaults file into memory and leaves it
    there.  Strings get converted to compound strings and two extra copies
    of each compound string get left allocated because of a "hole" in the
    current Intrinsics converter architecture.  My "guess" is that DRM
    is more efficient, although I have never run any tests on an application
    written both ways.  A number of the bundled applications switched from
    XRM in V1 to DRM in V2.  Maybe they can comment...

3.  Hard code all strings, locations, etc... into widget creation argument
    lists - this can obviously be the most efficient if coded properly
    (i.e. the developer knows what things can be freed when, how to avoid
    using XtSetValues when they can, etc...) since nothing is being read
    from disk.  But you will loose a lot of programmer productivity and
    run-time flexibility.  I wouldn't recommend doing it this way...

Leo