"Memory Resident Tag Properties"

Howdy,

This option, as far as I can tell, is undocumented. A google for “Memory Resident Tag Properties” yields one result where @Kevin.Herron mentions “As you can imagine given the name, there’s a tradeoff in that it uses more memory”

I’m looking to get more detail on this Memory Resident Tag Properties, maybe some documentation. Any kind of insight on this option would be appreciated… experience with performance, knowledge of the nuts and bolts, etc.

The questions I have off-top are:

What kind of performance gain could one expect vs typical memory usage?

Which properties get cached, the SQLiteHistorian.Tables.TAGPROPERTIES class?

Does this cache ever refresh?

Is there a ceiling for the amount of memory Ignition will allocate?

What is the technical advantage to caching in regards to tags?

Cheers

Hi,

First off: this discussion is for Ignition 7, as Ignition 8 is a completely different model where this is no longer applicable.

Also note: everything below doesn’t apply to UDT tags (definitions or instances), those always hold their properties in memory.

In order to reduce memory usage in Ignition 7, some tag configuration properties that aren’t frequently used (Documentation, tooltip, etc) are not loaded into memory. When needed, they are retrieved from the internal database.

The “when needed” part is the unfortunate aspect, as the full tag definition is required fairly frequently- any time a subscription of any sort is created in a Vision client, for example. As a result, there are several optimizations in place that pre-cache and bulk load tag definitions for these operations, so overall performance isn’t too bad.

Some use cases, however, can’t or aren’t optimized, and people run into problems. The main case is when people use scripts to dynamically browse/discover/read tags- for example, to synchronize tag sets with external systems. In these situations, individual tags are loaded as necessary, which can be quite slow.

This option simply holds all of the config in memory instead of going through the lookup process. It uses about 30% more memory. The thing is, as mentioned above, if you’re using UDTs, it does nothing… and if you’re not using UDTs, it’s unlikely that you’re going to have hundreds of thousands of tags, in which case memory won’t really be an issue. So, in practice, it’s a fairly narrow band of who actually needs it set one way or another.

In memory, in regards to your question about the “cache”, these properties can’t be changed on disk (although since you mention the table by name, you might think you can… but that was never intended), so there’s no reloading/cache invalidation. Ignition expects all changes to be made through the platform/api.

Hope this helps!

2 Likes

Yes! That is insanely helpful, thank you for the well thought-out and detailed answer.

Follow-up question:

It uses about 30% more memory

Per cacheable tag?

I see now how this is a narrow use case. I’m making a tag provider for persistent storage of gui resources that use browseTags to generate. I don’t imagine this option will make a measurable difference there, but I’ve now made an informed decision and learned a few things. Thanks again :blush:

Per cacheable tag?

Yes, it ends up being something like 1600 bytes a tag, fully loaded (very roughly). And that means history storage, alarming, scaling, etc.

1 Like

Is it possible to clear this memory manually? I am running across an issue where I will change UDT such as disable a tag, change UDT properties. I will still see these old values pop in the error logs in Autosol. They do not exist at all in Ignition anymore. I did a complete item list dump, reinitialize tags, and still see the old tags coming from Ignition. I spoke with Autosol support and they said Ignition is still requesting this data somehow, of course beyond that point was out of there scope. Any thoughts or suggestions on this? The only way to get them to stop is completely break the OPC connection temporarily and reconnect. This is not ideal as it impacts end users.