We’ve just been bitten by this too.
A touchscreen we use has a quite slow CPU, opening a motor popup took 1s to show the popup window, and another 7-8 seconds to visualise the tag data. During that time, the CPU was constantly running at 100%. I would have thought that opening a popup would be influenced mostly by network speed (getting the data from the server) or graphical power (rendering the screen itself), but it turns out to be CPU intensive.
Changing the popup to accept a tagpath parameter instead of an UDT parameter fixed the issue. It still take 1s to show the popup window, but all data is visualised immediately when the popup opens.
Strangely, it also doesn’t depend on subscribing to the UDT. When we were halfway through changing the references on that popup, we kept the UDT reference but derived it from the tagpath (which is easy enough to do via indirect tags). The popup already loaded twice as fast as before.
When you do it the other way around however, bind the tagpath to the UDT via the meta-data (and keep the UDT as parameter), the popup stays slow.
So it looks like for every lookup that needs to happen through the UDT (either directly or indirectly), a relatively large amount of CPU power is needed, while that isn’t the case when you use the tagpath without passing through the UDT meta data.
Having an unused UDT still defined as parameter on the popup doesn’t seem to make a speed difference, as long as you don’t use the UDT.
This is all very counter-intuitive to us, as we thought it would have been easier for Inductive Automation to optimise the CPU usage when using an UDT instead of referencing every tag value separately. And the issue isn’t related to subscribing to all tags, but instead related to how much you effectively read from it.
The only thing we can guess is that for every parameter read, the client will acquire the entire UDT to get the parameter from it, which sounds extremely wasteful.