BrowseTags is too slow for practical use

I currently have about 600 tags - all are UDTs , a few are complex containing nested UDTs. browseTags with recursion takes about 5 minutes to complete.

I am trying to create a backup of certain tags that I am using a filter to obtain. I call the method asynchronously so the operator can still go about operating the system but it is still not great since I don’t know when it is going to finish. I can possibly do manual recursion to get something of a progress, but I still feel there is something fundamentally wrong given the time it takes.

Is there anything I can do to improve the performance? I’d hate to see how long it would take for a decent sized SCADA project.

Try running it in gateway scope using system.util.sendRequest(). (in a background task still.)

1 Like

Amazing… I have never come across a case where it takes such a long time to calculate something in a 600 tags project. I am really interested in testing this algorithm on my machine. Is it possible?.

Are you finding the tags inside the UDTs too? It can be a lot more than 600 if so and may explain the time. Definitely implement the manual recursion part (its on the 7.9 version of browseTags, here), it helps a lot. Also like @pturmel said, use the gateway. Personally I use a dataset memory tag + a gateway timer script that will run the script every so often and write it to the dataset memory tag.

1 Like

I will try this, I was wondering how to work out/control where the bulk of the work being done by the function was executing.

Sorry if i mislead, but as @mrogers mrogers pointed out, it is around 600 base UDT tags, each containing a few other tags and a couple containing a range of other UDTs I can’t unfortunately, provide you a copy of the project, but to give you a feel for the actual breadth/complexity of the tags, (on average about 5) OPC tags which are packed words which I decompose using boolean expression tags (on average about 8 or so), and then I have a couple of derived tags (about 3 or so) which act as links to other tags within the structure located in a single folder that I can filter on easily using browsetags. This might be for an analog for example. Then I have a handful, 10 or so, complex UDTs which are similar in structure but additionally have about 70 or so analogs for example. So yeah thinking about it, it is a lot more than 600 tags that have to be scanned from browsetags, but I still consider this a small project, because if i were to use a scada system which didn’t have the ability to produce these nice structures, i would just be keeping the OPC tags and working with them as whole tags, and decomposing on the fly… But I am trying to leverage the features to make my life easier, at least during development.

I will try this, I didn’t think manual recursion would help with time, I just thought it would break the task into chunks that are more manageable resources wise (which I don’t have a problem with). But I will give this a go I should have tried this.

This is kind of what I am doing, but with derived tags. The problem arises when iterating through all of these tags before I store them in a database. Although the use of a dataset does seem like a good idea, as it will reduce my tag count at least instead of having several derived tags. I will try this as a last resort, since it would require a fair bit of rework for me at this point.

Thanks for all the responses so far, I will let you know how it goes.

1 Like

Heres another suggestion that I’ll try to explain. Basically, do a manual recursive search for all UDTs, just the top level UDT part, not down deep into it. Then for each UDT type, select one from your list of UDTs, and search through that to get a list of the tags inside it. Since that tag structure is static with each UDT, you can extrapolate that structure to every other instance of that UDT, to get a complete full list, when you’re really only going to each top level UDT and doing a couple other searches on each UDT. Depending on how many UDTs you’re spread out on, it could provide a big improvement.


Some times, certain features are excellent from engineering perspective but may turn out to be a overkill when it comes to performance. I suggest, you try the alternative approach also as a safety net.

1 Like

I tried executing on the gateway, but unfortunately it didn’t seem to have any improvement that I could notice.

I tried this and a “big improvement” is an understatement! From 5 minutes, its now down to 3 seconds!!! It was fairly convoluted code, getting the data type was not as straightforward as I had anticipated (needed to do a to get it, which I subsequently optimised into a system.tag.readAll batch) but the result is well worth the time spent. Now I just need to clean up the code…

Yes I agree, this is the first ignition project I have undertaken, it was hard to know what to expect when it comes to performance in advance, but I’ll put it down to experience. The other thing that comes to mind that this also exactly applies to, is passing UDT paths instead of complete UDTs to templates…

Anyway, thank you all for your help!


You could try system.tag.browseConfiguration. It might be faster. Also, you could try caching the results so subsequent access to the information is already hot.