I don't know all the details of tag()
's problems, but I suspect there are two key contributors:
-
tag()
startup tries to supply a proper initial value, with a 1-second timeout, on startup everywhere it is used. Use a hundredtag()
calls in the bindings on a Vision template or window and you can block your UI for up to a hundred seconds, looks like. Not sure how Perspective's parallelism fits here, but you'll either tie up a thread for a hundred seconds, or tie up a hundred threads from the Perspective pool, or somewhere in between. Mytags()
function deliberately does not attempt to do this. (Indirect tag bindings don't do this, either.) -
Every
tag()
expression function is in its own little world, and will trigger expression re-execution where it is used, whenever a new value shows up. If you have twenty tag changes for twentytag()
functions, you will get about twenty re-executions. With mytags()
function, if twenty of the tags get new values within the configured timing window, you get one re-execution.
On top of that, I am offering a "one-shot" non-subscription mode that functions like a large list supplied to system.tag.readBlocking()
. Without the jython overhead.