Dynamic Template Repeater Popup Performance

Ignition
1

Working with multiple vendors and in-house programming and development. We are running into an issue with thrashing when we open a popup that uses dynamic template repeaters because the cache is dumped when the popup is opened and the data being passed in is different from when it was opened last.

  • Tags are mapped to UDTs that use datasets and custom properties to drive objects in a popup.
  • Popups have tab navigation that make visible a template according to which tab is selected
  • Opening a popup passes in a tagPath parameter that is then passed into the templates for indirect bindings
  • Most templates utilize a template repeater driven by a UDT memory tag dataset and custom properties to populate the repeater with the correct "row" template and organize the order in which it is displayed
  • These are device specific popups. i.e. analog in, analog out, discrete in, vfd, etc. the purpose is to avoid having vendor specific popups that need to be maintained by having generic or vendor specific templates that can be passed into the repeaters.

Is there a way to increase performance and not just turning off overlays and invokeLater enabling of the overlays after everything has loaded?

2

First, what version of Ignition are you using?
Second, have you/are you able to quantify which phase of execution is slow? I.E. is it reading the tags, populating the custom properties, actually constructing the templates, etc?

3

Ignition 8.1.31

Im not able to say which phase is actually slow. My guess is that its a combination of populating the custom properties and constructing the templates.

Edit:
The part that is slow is loading the templates into the repeater (1-2 seconds)

4

So, my first recommendation would be to contact support. They can work from an export of your project/gateway and try to reproduce the problem in house, which would help us determine what's going wrong and where, and whether workarounds are possible or if you have to wait for us to fix some bug.

Another thing you can try to do, just to collect more information, is just to set as many loggers as you can see to debug or trace level in a given client session, then perform whatever 'slow' operation. You'll probably have to 'shotgun' at first, since we're not sure exactly where the problem lies, but there's going to be some useful debugging and timing information in those logs.