Suddently Slow Refresh / Page Painting (Symbol Components?)

[MrDeathStar]

One of our applications that typically runs continuously for many weeks/days suddenly became extremely slow (over this past weekend). The operator experienced page refresh rates of 1800 to 3200ms on pages usually running 70 to 300ms.  Application threads seemed to be running at expected rates with typical 'delay' intervals.  Logging and data acquisition did not appear to be affected, just screen repaint performance.  Channel data history lengths had reached their limits many days earlier.  DF was the only application running.

The application is built as a sequence of tabbed "pages" where a tab's page is shown by merging it with the main control page.  Each page can be separately displayed (without being merged) through the DF interface.  Surprisingly, some pages containing several graphs were found to be fast, while other page seemed to be abnormally slow.  The common element on those pages seemed to be the Symbol components.  However, creating a new page and adding a symbol did not seem to be a problem.  The pages with symbol components are typically just small icons and such for custom looking buttons, and the graphic shown may depend upon some variable value.

This is the first time we have experienced this issue with DF (though we have been previously using 15.9x versions).  Have there been any reports concerning symbol components (i.e. or internal DC memory handle leaks, etc.) that might explain the sudden speed decrease?  The only solution was to restart the application, which required an experiment interruption, but all started working again as expected.

Thank you for your time.

DF: 16.3

[AzeoTech]

Hmm, I wonder what your memory usage looks like at that point?  Can you send or post us your .ctl document and tell us which page is causing the problem?

[MrDeathStar]

I will need to determine if the company will allow us to share the .ctl document as the experiments are under IP.  However, I can comment on the behavior.  Yes, the memory usage of DF was higher than other applications we have created...approximately 1.2GB at the time of the event.  All charting and channel histories were full and working as expected.  I am sure that could contribute to an issue, but the application has been in use for several months without issue and was recently restarted last week (before the problem was observed.)

While all pages in the application were slower, the typically slower pages having graphs were not impacted as much (maybe only twice as slow).  Pages containing button, text, variable value and symbol components were far slower.  (I only guessed symbol components could be the issue because two pages not having them were far faster.) The 60ms main page, for example, went to 780ms by itself.  It contained a handful of buttons, panels, and symbol components.  The application does use a few canvas components too, but not on all pages.  The pages with canvas components have several symbol components as well, so it is hard to separate.  The slowest page is usually about 250-350ms, but was operating near 3000ms.

The application is using LabJack and makes calls to the LabJack library directly.  The main threads for collection and logging were reporting correct delays, etc.  The command / alert console window (as always) was in use heavily, but newly created pages were fast.  So it could be that accessed something was slower, but the main page does very little.  It is true that several screen components do make calls into a common script object to collect state (very quickly conditionally accessing different local variable members), so it is also possible that if that object was somehow 'locked' too long in script it could delay rendering.  That common object only handles GUI state and has a fast background thread to monitor state from other application objects.  Is uses a 1-2 second delay between attempts.  The application is written using several processing threads managing their own event 'queues' to avoid contention.  The thread processing seemed to be operating correctly during the slowdown...only screen updates and general slowness in the GUI were observed.

It appears this may be an unusual condition so we will continue to monitor it and report again if it occurs.  I submitted another strange edit box problem observed once and wonder if it could be related, as it too is a GUI control element.  I welcome any further comments you may share.

[AzeoTech]

You can email us the doc directly instead of posting it.  Also, you can reduce the document down to just the page in question if you want.