isCOBOL Evolve : Appendices : Performance Tuning : Guidelines for better runtime performance : User Interface Optimization
User Interface Optimization
The isCOBOL architecture separates the UI from the back end processing using a client/server logic. The UI is managed by the client part while the back end is managed by the server part. Every time the user interaction causes some COBOL code to be executed (e.g. the user leaves a field that has an After Procedure) and everytime the program must update the video or accept the user input, client/server traffic is generated.
When the client part and the server part are executed by two different JVM processes (e.g. in thin client) then the performance may be affected by the client/server communication and the below suggestions beneficial effects will be more evident.
The main objective is to reduce the number of embedded and event procedures handled by the program so that the user interface must not send too much information to the server part while the user is interacting with it. For example, if you take advantage of Before and After procedures to color the current Entry-Field while the user navigates on the screen, then you may think to instruct the runtime by setting iscobol.gui.curr_bcolor and iscobol.gui.curr_fcolor properties in the configuration instead of coding embedded procedures.
UI changes bufferization
isCOBOL includes an internal optimizer that gathers data of all DISPLAY and MODIFY (if the GIVING clause is omitted) statements and sends this data to the client
• when iscobol.gui.cstimeout * expires
• when iscobol.gui.csmaxbuffersize * is reached
• where either WFLUSH-REFRESH or WFLUSH-ALLOW W$FLUSH op-codes are called
• when an ACCEPT of user input is performed
• when the CBL_READ_SCR_CHATTRS routine is called, or the equivalent statement ACCEPT dest-item FROM SCREEN is performed
• when an INQUIRE is performed, unless WFLUSH-INHIBIT W$FLUSH op-code was called. Note that not all INQUIREs cause network traffic, it depends if the Framework needs to communicate with the UI in order to retrieve the inquired attribute.
• when a MODIFY with GIVING clause is performed, except for TREE-VIEW’s ITEM-TO-ADD
• when a MODIFY of VISIBLE or ENABLED properties is performed on a window handle
• when a SET INPUT WINDOW or a SET I-O WINDOW is performed
• when a print file or a file whose class is “com.iscobol.io.RemoteRelative” is open
• when a CALL CLIENT is performed
• when events are generated client-side (it may happen in a multi-thread environment where the user interacts with the screen while another thread is performing MODIFY or INQUIRE that are being gathered by the optimizer)
Event Lists
isCOBOL also offers the ability to discard some events so that when they happen the client doesn’t communicate with the server. This feature is obtained by setting the EVENT-LIST and EXCLUDE-EVENT-LIST properties. See Controls Reference for details.
The drag events of Grid control can be disabled also through the configuration property iscobol.gui.grid.no_cell_drag (boolean) * or the style No-Cell-Drag.
Programming Tips
Some tips to write programs optimized for the client/server environment:
• use MODIFY instead of DISPLAY to update the screen. Modify acts on a single property, while DISPLAY redraws the whole control (or screen)
• if possible, avoid using the GIVING clause with MODIFY unless you’re using Item-To-Add in TREE-VIEW
• use absolute values for LINE, COLUMN, LINES and SIZE properties
• rely on the MASS-UPDATE feature when you need to load a Combo-Box, a Grid, a List-Box or a Tree-View
• setting iscobol.gui.curr_bcolor and iscobol.gui.curr_fcolor in the configuration is preferable than changing the EntryField colors in its embedded procedures.
• setting Row-Cursor-Color (or Row-Cursor-Background-Color and Row-Cursor-Foreground-Color) in the Screen Section is preferable than changing the Region-Color (or Region-Background-Color and Region-Foreground-Color) property inside Grid event procedures.
• rely on the Search-Options and Search-Text properties instead of scanning the Grid content with a loop of INQUIRE of the CELL-DATA property when you’re looking for a text in the Grid.
• rely on ACTION-COPY and ACTION-EXPORT instead of scanning the Grid content with a loop of INQUIRE of the CELL-DATA property if you need to implement the copy of the Grid content to a Excel spreadsheet or to the clipboard.
• huge processing cycles that periodically display the progress can be made faster by disabling the update of the UI by calling WFLUSH-DISABLE-UI before the processing and then calling WFLUSH-ENABLE-UI when the processing is completed.
• if a lot of INQUIREs must be performed (e.g. if you have a cycle that checks the content of each row in a Grid), consider buffering them through WFLUSH-INHIBIT and WFLUSH-ALLOW.
• attach embedded procedures only to those controls where you actually need to do something when the focus is gained or lost and avoid defining embedded procedures on Screen group items as they would be executed for every control in the group.
• Use Format-String on ENTRY-FIELD only if you actually need it and avoid using PIC if the picture doesn’t include any kind of editing (e.g. there’s no point in having PIC X(10) among ENTRY-FIELD’s properties). FORMAT-STRING and PIC generate client/server traffic.
• Delay the NTF-CHANGED event by setting iscobol.gui.entryfield.notify_change_delay * in the configuration (if you wish to affect all the entry-fields) or by modifying the property Notify-Change-Delay (if you wish to affect specific entry-fields). If the user types quickly, the runtime would generate too many NTF-CHANGED events. With this delay you can reduce the number of events generated.