# Tag Read During Tag Change Script Performance

**URL:** <https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716>\
**Category:** Ignition\
**Tags:** ignition81, scripting\
**Created:** [December 9, 2025, 9:34pm UTC](https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716 "2025-12-09T21:34:36Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\
**Post date:** [December 9, 2025, 9:34pm UTC](https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716/1 "2025-12-09T21:34:36Z")

</div>

I’ve got a tag change script that will need to read some other tags on the gateway, but one of those tags is an “enable” for the rest of the script. Is there any advantage to reading the one “enable” tag first, and then reading the rest if it’s actually enabled? Or, would that actually _negatively_ impact the performance of the script since it will now have 2 calls to `system.tag.readBlocking()` instead of 1 (when enabled, of course).

My intuition is telling me that a single read vs 2 reads is going to be better unless we’re talking 1000+ tags.

Thoughts?

---

<div class="post-metadata">

**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\
**Post date:** [December 9, 2025, 9:39pm UTC](https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716/2 "2025-12-09T21:39:11Z")

</div>

I haven’t done any bench testing, but on a customer project that doesn’t have transaction groups; I read all tags, and if machine status is auto, write to the DB. So I opted for the single read call.

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [December 9, 2025, 9:47pm UTC](https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716/3 "2025-12-09T21:47:41Z")

</div>

> [@Matrix\_Engineering](#):
>
> write to the DB

With the SF functions I hope!

---

<div class="post-metadata">

**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\
**Post date:** [December 9, 2025, 9:54pm UTC](https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716/4 "2025-12-09T21:54:01Z")

</div>

Of course aha.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [December 9, 2025, 10:10pm UTC](https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716/5 "2025-12-09T22:10:28Z")

</div>

If you are dynamically generating the corresponding tag paths, I'd use a separate read to avoid the path list generation. If the list is static (or cached in a script module top level dictionary), I'd read up to a hundred or so unconditionally.

---

<div class="post-metadata">

**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\
**Post date:** [December 9, 2025, 10:22pm UTC](https://forum.inductiveautomation.com/t/tag-read-during-tag-change-script-performance/112716/6 "2025-12-09T22:22:14Z")

</div>

It’s a static list of other tags within the same UDT