<< to CrossControl homepage

Support & Service Center

Optimizing performance

Printer-friendly versionPrinter-friendly versionPDF versionPDF version

As with all other development tools you can realize functionality in several ways, both good and bad. Below is described some Best practices that could and should be considered when making a good looking and well performing QuiC application.

Functional

  • Avoid using global conditions to detect Key presses. This type of comparisons will be ignored if the Key is already being used (consumed) by the screen.
  • When navigating to another screen, use the “Go to Screen” script rather than the “Link to Screen” script.  Liberal use of “Link to Screen” script may result in exceeding the maximum linked screen limit allowed by the display unit, which is 10. When the 10th screen is stacked using “Link to screen”, the oldest screen will be removed.
  • ALWAYS use the “Set Units” script to change the units setting of the display during runtime.
  • In the Screen Designer, when using Text Objects that contain a large number of text characters, the rendering will become very slow, which will result in difficulty when moving the object on the screen.
  • For additional design-time considerations, please reference the Help contents, which is available in the QuiC Deisgner Tool.

Performance

  • Minimize the use of Global conditions, since they are evaluated during every loop, independent of which screen is active. Instead attach Conditions to specific screens.
  • Avoid using “deeply nested” calls.  For example, nested calls to “Call Script” and “Call Condition”.  In addition to added complexity, the processing time will increase because main execution will not continue until all script actions have been completed.
  • If you have much information you want to show on the screen, try to divide those data controls into separate screens, see next screen for a more detailed description of how different controls affect the performance.
  • Minimize the number of objects requiring data entry on a single screen.  Screen response time may diminish, depending upon the amount of data to be entered by the user.
  • The ”Set Delay” script will run to completion before executing the next action in a script.   While objects will still be evaluated during a delay pause, the delay may cause an unexpected block of other user interface actions.  Consider the alternative of using a System Timer, which will run in the background and execute another script when the timer expires.

Performance cost per component

Each graphics component on the screen consumes time during each loop. So, adding more components on a screen is also adding time to the loop time.
The list below shows approximate time consumption for each type of component:

  • Data bar = 21 ms
  • Digital =  12 – 38 ms
  • Bitmap Small = 4 ms
  • Bitmap Large = 27 ms
  • Conditions = 3 ms
  • Scripts = 2 ms
  • Gauge Large = 25 ms
  • Gauge Small = 2 ms
  • Gauge medium = 15 ms

Some additional guides

  • A data bar will not always take 21 ms, it depends on the size, the placement and other rendered objects
  • Larger images cost more
  • Conditions do not take much time, but they stack
  • Scripts do not take much time, but they stack
Environment and Versions: 

QuiC Tool: 2.2.0.0

QuiC RT: 2.2.0.0

However, this guideline is valid for other versions also.

Category: