Conference bulova::decw_jan-89_to_nov-90

What cost are you measuring ?

If you roll your own, you will certainly have higher development costs.

If you need to be compatible with the DECwindows, XUI, or OSF style, then
rolling your own will be much more costly since will need to track the changes
that take place in those areas.

If the users don't have the degree of customization that they expect,  either
the users pay the cost of inconvenience and aggravation, or they will force
you to pay significant costs in support.

If compatibility is not an issue and never will be and if performance is
critical in the short term, then it may make sense to roll your own.  However,
in the longer term, we expect the hardware speed to increase to the point that
the generality of the current widgets won't be a signicant cost.  I'm convinced
based on observation that the things supported by widgets are not much more
responsive on a PMAX over a PVAX even tho the platforms differ in speed by
a factor of three.  One things happen in a blink of the eye, half a blink isn't
much more impressive.

    This reply assumes "expensive" means in machine resources... 
    
    The Good News: The perceptible speeds of Xlib and XUI toolkit
    applications are similar after they have started up. Menus and stuff
    come up acceptably fast even on MicroVAX IIs. This assumes, however,
    that you don't page and have the cpu to yourself. 
    
    The Bad News: If you use the XUI toolkit rather than Xlib, your program
    will likely take much longer to start up (perhaps 10 times longer,
    around a minute on a MicroVAX II), and you will use lots more memory
    (say an extra half meg minimum). These are very rough "order of
    magnitude" figures. The more widgets you have going at any one time,
    the more memory it costs (startup is also slowed by many widgets being
    created at the beginning). 
    
    As .1 tries to point out, it can be a lot harder to program pure Xlib,
    especially if you want to do such things as cut and paste which depend
    on the (still not wholly defined) interclient communication
    conventions. 
    
    What people often wind up doing, as an intermediate thing between XUI
    and pure Xlib, is writing private widgets for the application's work
    area (or using the window widget if you can live with its limitations).
    This technique requires some direct use of Xlib, but lets the toolkit
    handle a lot of the hard stuff. A rough rule of thumb from Leo
    Treggiari was to use a private widget if building your work area from
    XUI widgets would require more than 100 of these. 
    
    See also note 1366 in the old conference...

A minute to start up?  Even the more complex applications (like DECwrite)
and even with early baselevels didn't seem that bad.  Certainly a minute
is NOT a "typical" time to start up for a microvax (under VMS at least,
that's all I've seen).

	paul

    I just did tests with my wristwatch:                   
    
    a) dxclock on Ultrix  20 seconds
    b) small user-written XUI application on Ultrix  15 seconds
    c) decw$clock on VMS  25 seconds
    
    I'm very sorry to have said one minute, that was wrong.

I used to run DEC$MAIL locally on my 6mb VS2000.  It took anywhere from
1.5 minutes to 2.5 minutes to start (FT2).

I now always run my applications remotely (on an 8550 or 8800) and they
usually come up in 10-20 seconds. (SDC)

I've seen 14mb VS2000s and they appear almost as snappy as 8mb PVAXes.

	Ken

(waiting for the memory...)

    The numbers in .4 are for 9 Mb VS II/GPXs. The extra 5 seconds on the
    VMS machine may be because the machine had a lot applications started
    up already. The Ultrix one was just running xterms. The VMS GPX has an
    RD54 as system disk, the Ultrix one has two RD53s.