Discussion on Performance of Reference Tags

Ignition
,
1

Purpose

To discuss the underlying implementation of the Reference Tag in the Ignition Gateway Provider. The hope is to keep the conversation targetted in two areas:

  1. Initialization/Startup Overhead
  2. Ongoing Overhead

Background Reading

Early discussion on purpose/function of a reference tag: link

Observations

  1. Reference tags have an obvious impact to the config.idb structure. While minimal in relative terms, it is "heavy" in absolute terms, in the sense that config.idb is storing tag information as json.
  2. From the above, there is at minimum a necessary initialization overhead to introducing reference tags into a tag db
  3. From Colby in the above link:

[reference tags] aren’t much different than what you mentioned - expression tags, or more directly, derived tags. They are lighter weight than both of those in that they don’t create expressions in memory

  1. The above does not preclude the possibility that there is still a light to moderate amount of memory overhead associated with reference tags

Targeted Questions

  1. "Under the hood" (inside of the gateway), what is the initialization effort required to get a Reference Tag "up and running". Perhaps useful to discuss in Big(O) terms.
  2. What is the ongoing cost to maintain a reference tag in memory terms to the gateway? Is this closer to a pointer (i.e. close to free), or closer to a copy

Discussion

I have recently had great success with Reference tags in generating dedicated MQTT Tag Providers for ingress and egress operations in and out of Ignition Gateways. The overhead is, at least apparently, very small, but because my environments have a lot going on, it is difficult (basically impossible) to isolate their performance against everything else going on. It quite obviously beat the alternative of allowing MQTT scanning of our existing Tag Provider, and so I was content with the alternative.

More recently, I have found alternate applications for reference tags that fall in the category of bringing data closer to perspective with Reference Tag-based UDT structures. This pattern model is quite aesthetically nice, and providers downstream user with easier access to core data without having to search too much for it. As noted above, this does necessarily come with some tradeoff in performance. I mentally model these as pointers, but I don't have any direct evidence for this, and I can't seem to find much clarity in any documentation or Forum topics (excluding the above).

I wished to open up this topic to discuss in more detail what the implementation looks like for these tags so I can get a better sense for what the trade off is for the obvious benefit of collecting data in a central place without replicating data capture.

Thanks,
Bobby

2

  1. You are asking IA insiders to share proprietary information. Some might, but don't expect many details.

  2. If you are trying to work around the limitations of data delivered with custom tag providers, like MQTT tags, then Reference Tags are the lightest possible weight tool. If you must do so, use the Reference tags and just absorb the slight performance impact.

User interfaces are lightest weight when there is substantial re-usability, and that is most true when views are designed to take a tagpath string parameter, where the tag tree named has predictable inner tag/folder/UDT names. This typically requires organizing tag names that may not match the native names in a PLC.

When using OPC tags, this is accomplished inside the configuration via its OPC Item Path--it does not have to correspond to the Ignition tag name at all. When using managed tag providers to ingest the data, this isn't possible, and the Reference tag is the next best thing.

Making your GUI application light-weight with easily-reused components and views will more than make up for the light performance hit from Reference tags.

Also, config.idb carries, mostly, configuration information. It's penalty is light as long as you aren't reconfiguring tags (much) at runtime.

TL/DR: You are worrying about something that you either cannot avoid, or saves more than it costs, or both.

2 Likes
3

Thank you Phil! This response is at the heart of my intuition as well, so I feel better about it being echoed back by you, sincerely.

wrt:

You are asking IA insiders to share proprietary information. Some might, but don't expect many details.

I certainly don't expect details, and just reassurance of a Big(O) mental model would be incredible. But frankly, a Phil endorsement is pretty darn good.

Thanks again!

1 Like