# When to use system.tag.writeAsync instead of system.tag.writeBlocking? **URL:** \ **Category:** Ignition\ **Tags:** ignition81, scripting\ **Created:** [February 6, 2025, 9:02pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008 "2025-02-06T21:02:30Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\ **Post date:** [February 6, 2025, 9:02pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/1 "2025-02-06T21:02:30Z")
Should the [system.tag.writeAsync](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-writeAsync) function always/generally be preferred over the [system.tag.writeBlocking](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-writeBlocking) function when doing a scripted tag write and the remaining script execution does not read or otherwise depend on that tag? Early on in my Ignition learning I just defaulted to using the [system.tag.writeBlocking](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-writeBlocking) function in almost all cases, as the examples in the Ignition documentation seem to use that exclusively. I suspect it would be better to use the [system.tag.writeAsync](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-writeAsync) function when performing a large tag write (many tags at once) but when performing one, or a few, tag writes at once might it be more performant to use the [system.tag.writeBlocking](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-writeBlocking) function and avoid the overhead of spawning new asynchronous threads? Known exceptions: - When writing to the same tag multiple times and each write should be processed in a given order (e.g. for tag history). ---
**Author:** ![bschroeder](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bschroeder/32/13260_2.png) [@bschroeder](https://forum.inductiveautomation.com/u/bschroeder)\ **Post date:** [February 6, 2025, 9:18pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/2 "2025-02-06T21:18:58Z")
Typically I use writeblocking in operations that users would expect a slight delay. Buttons, etc...where bindings aren't possible. An async script might show that something is written but isn't actually to the operator. Tag Scripts, Tag Event Scripts, anywhere a thread lock isn't desired, etc.. we attempt to exclusively utilize async writes. I don't believe that writeBlocking multiple tags vs writeAsync will have any difference in backend performance. However, blocking locks the thread while the writes are being done. Which could in some places cause issues, and in other places will cause issues. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [February 6, 2025, 11:14pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/3 "2025-02-06T23:14:15Z")
> [@tyler.bennett](#): > > avoid the overhead of spawning new asynchronous threads? Neither writeAsync on the client/designer nor the gateway generates asynchronous threads directly - they recycle threads from an internal pool. In _general_ though, the overhead of successive _network_ operations dwarfs the overhead of thread creation, so the most important thing is to batch your read and write calls together. There's plenty of other advice about when to avoid blocking in particular as well, and in general if you don't actually need a return code or to block execution, sure, go with writeAsync by default. ---
**Author:** ![mike.field](https://avatars.discourse-cdn.com/v4/letter/m/8e8cbc/32.png) [@mike.field](https://forum.inductiveautomation.com/u/mike.field)\ **Post date:** [February 3, 2026, 4:25pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/4 "2026-02-03T16:25:32Z")
Bumping this a year later. I have been using writeBlocking up until this point as I really haven’t had much issue with it. Now I am working on a project where I need to write up to 30 tags at once and writeBlocking is taking approximately 1.2 to 1.5 seconds to complete. Would writeAsync be a better option for faster execution? I am already grouping all together and having one write instruction for the batch. This is for a process where reducing by one second per unit is a huge difference. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [February 3, 2026, 4:29pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/5 "2026-02-03T16:29:17Z")
Moving to writeAsync may reduce _apparent_ latency (basically only if you're in Vision) but will not actually make the wall clock time to write the tags any faster. If writing 30 tags takes more than a second, that suggests a more pathological issue. Changing scripting functions might be putting a bandaid on a gunshot wound. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [February 3, 2026, 4:30pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/6 "2026-02-03T16:30:11Z")
> [@paul-griffith](#): > > If writing 30 tags takes more than a second, that suggests a more pathological issue. Changing scripting functions might be putting a bandaid on a gunshot wound. Indeed, I've written to hundreds of tags at once in milliseconds. ---
**Author:** ![mike.field](https://avatars.discourse-cdn.com/v4/letter/m/8e8cbc/32.png) [@mike.field](https://forum.inductiveautomation.com/u/mike.field)\ **Post date:** [February 3, 2026, 4:33pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/7 "2026-02-03T16:33:53Z")
Little background then. This is on an Omron CS1 PLC using the Omron FINS driver. This is a tag change script in the gateway that is executing this code. Basically, new Serial number is detected, then we call a SQL Named Query, then write the results of the named query to some tags, the most being about 30, mostly integers. I tried the writeAsync and the script execution time went down to a few milliseconds. Would this be correct or is this just an apparent fix? Thanks for the quick replies though! ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [February 3, 2026, 4:38pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/8 "2026-02-03T16:38:55Z")
You've basically just offloaded the latency to a different pool. The reported execution time of the change script is indeed reduced (because the tag change script gets to keep executing after the `writeAsync` call), but the actual write operation is still going to take as much time as it does via `writeBlocking`. As long as the latency there is acceptable to you, then carry on. If you don't need to analyze the results of the write operation and it's the last thing in your script, you can use `writeAsync`. I would worry _slightly_ about obfuscating your latency; if the writes suddenly start taking thirty seconds, are you going to remember to look at the tag change script that still completes in milliseconds? ---
**Author:** ![mike.field](https://avatars.discourse-cdn.com/v4/letter/m/8e8cbc/32.png) [@mike.field](https://forum.inductiveautomation.com/u/mike.field)\ **Post date:** [February 3, 2026, 4:43pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/9 "2026-02-03T16:43:08Z")
Thanks Paul, I am going to switch it back to writeBlocking for now since historically, this line (we are testing out Ignition to reduce latency compared to the Wonderware instance that has been here 20+ years) has had issues with data corruption when being written to from outside the PLC. I will start a different thread elsewhere to combat the latency that is there since it seems like writeBlocking should not be taking that long with 30 tags. Thanks, Mike ---
**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:** [February 3, 2026, 4:47pm UTC](https://forum.inductiveautomation.com/t/when-to-use-system-tag-writeasync-instead-of-system-tag-writeblocking/102008/10 "2026-02-03T16:47:54Z")
You should keep in mind that an overloaded driver for ordinary tag subscriptions will impact write performance. ~~What brand and model of PLC is this? And is this an IA driver or a PLC-supported OPC connection?~~ (Perhaps start a new topic....)