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!
