Conference bulova::decw_jan-89_to_nov-90

> He has about 300 widgets in total, and is having problems with slow selection
> of an item in a list box (~24 items).

300 widgets is not a large DECwindows application. What kind of configuration
does the application run on? You could also take a look at the Vlist widget in
the Examples conference. The Vlist widget is a lot faster than a list box.

Olav

    300 widgets may not constitute a "large" application, but when compared
    on any platform to an application which starts with 30 widgets, it is
    a "slow starter".
    
    In one application I keep a vector of flags that tells me whether the
    widget sub-trees have been created or not.  I start a toplevel and a
    few widgets, add a work procedure and then enter main loop.
    
    As the user is thinking, my work procedure will fetch the next 
    unfetched sub-tree and return to main loop.  When all the sub-trees are
    fetched the work procedure is removed.
    
    If the user clicks into a part of the UI that's not been fetched, the
    callback routines know to check if the widget exists first before using
    it.  If it doesn't exist, the appropriate sub-tree is fetched
    immediately.

    The approach which Patrick describes in 1395.2 is the approach that
    DECwrite uses (it was not abandoned).  If DECwrite were to build its
    entire interface before processing any events, there would be a 30
    second delay before the user could do anything.
    
John

    That's great.
    
    It adds a lot of credibility if this is what DECwrite uses, because I
    have demonstrated DECwrite to them, and they know how complex that is.
    
    Would it be too much to ask for some examples (or fragments of code ) ?
    
    The documentation seems a little sketchy.
    
    Cheers.
    
    Mark.

    
    What's the configuration they're testing performance on, and what
    startup times are they experiencing?  Do they know what portion of
    their startup time is taken up in loading the UID?  Given that data we
    might be able to tell if what they're seeing is expected or an abnormal
    overhead.

    Well, the configuration is a fairly small machine, but I guess that
    they may have a problem with setting their machine up correctly.
    
    I'll propose this solution, once I've had a bit of a play with it
    myself (why I'm staying late tonight).
    
    They are not using UIL unfortunately. They acknowledge that it is
    better, but want to write this application over from UIS, as a set of
    routines. I assume from this that they have worked out all the event
    handling. Most of the application is written in Fortran with all the
    toolkit stuff written in 'C'. They say that they will eventually
    convert the rest of the stuff to 'C', but it is a fact of the couple of
    developers who know and love 'C' persuading the rest.
    
    Thanks for the help.
    
    Mark.

I've spoken to the customer again, and got some more details.

They already use work procedures, but they use them for compute functions.
Apparently, the work procedures never take a time, but they do exist, and
as far as I know, go on all the time the application runs. What they find
going from UIS to DECwindows is that selection of widgets in a dialog box
is generally slow. This is especially noticeable to them when they do a
list box, but can be seen on a radio box with a lot of options.

It occurs to me (maybe someone can tell me if I'm right or wrong) that a
list box selection could generate multiple events, and if between each
event, the work procedure gets in, then it could slow down the running of
the program.

The program itself comes from the MOD, and is sensitive. I'm trying to get
the user to hack together an example that illustrates this. If he is forth-
coming with the code then hopefully, I can help him out.

I've also asked him to check with the system manager, what the user param-
eters are (they run diskless VS3100's booting off a big VAX). If the working
sets are too small, then I think this could ruin performance.

Could you confirm or deny the behaviour of the event loop concerning list boxes?

Mark

The work procedures and the working set parameters are definitely the things
I would look at.  One question I'd ask them is whether the dialog boxes
of their application are any slower than the ones in the OOTB applications
(like DECterm, Session Manager, etc...).  I so, then it must be something
specific to their application or the process it runs in.  If not, then it's
likely insufficient memory on the system (or a badly tuned system...).   If this
workstation was previously running UIS, then there are some system parameters
that you need to "crank-up" for UIS, that just waste memory for DECwindows
(sorry, but I can't remember specifically which ones...).

> They already use work procedures, but they use them for compute functions.
> Apparently, the work procedures never take a time, but they do exist, and
> as far as I know, go on all the time the application runs. 

Having a work procedure registered all the time is not a good idea.
The *least* problem it will create, is that the application is *always*
in a "busy loop"; it is *never* just sitting waiting for events (as "normal"
DECwindows application do...).

> It occurs to me (maybe someone can tell me if I'm right or wrong) that a
> list box selection could generate multiple events, and if between each
> event, the work procedure gets in, then it could slow down the running of
> the program.

The work procedure won't run when there are events for the toolkit to
process, so having an empty work procedure always registered should not
slow down your application much, but could impact the *system* for the
reason I mentioned above.

> I've also asked him to check with the system manager, what the user param-
> eters are (they run diskless VS3100's booting off a big VAX). If the working
> sets are too small, then I think this could ruin performance.

Definitely...

Leo

Well, I had a go at creating a sample application.

This was from a DECwindows thing I always meant to finish, but never had the
time to. Everyone else seems to have written a Fish Bowl program, so I thought
I'd have a go.

Anyway, instead of fish, this program uses a timeout procedure to move graphics
lines around the screen (like string art), the dialogue box under "New Fish..."
allows the timeout period to be varied by the swim speed slider.

This illustrates the problems mentioned in .8 about having a work procedure
running all the time. With a timeout of 0, the timeout procedure works like
a work procedure, and takes up all of the available CPU time. Changing the
timeout value to 1, doesn't appear to degrade the performance at all, but
does mean that the application hardly appears to use resources at all!!

I shall have a further chat with the customer and try to find out what they
are doing with the work procedures.

For anyone who is interested, the program can be found in

TASTY::TASTY$DUA0:[JEFFERY.MYFISH]  FISH.C, FISH.UIL, FISH.EXE, FISH.UID

Cheers.

Mark.