Slow loading times after 8.0.14

[Tbthomps]

I’ve got a perspective view with about 32 of the same inherited global template on it that pulls tags from a remote tag provider. When I open the view on version 8.0.14 they seem to load in chunks per section (4-5 templates load all at once) fairly quickly and I never had issues. I upgraded to 8.0.15 RC1 awhile back and had to downgrade because it seemed like they were loading 1 template a time which would take 2-3 seconds a piece then would move onto the next one. This took quiet a bit of time to load when jumping between pages. I downgraded back to 8.0.14 and the problem fixed itself. Now I need to make use of the idp user info that was released in 8.0.16 so I just loaded the RC1 candidate and my issue is back. But now if I load into a page I’m getting most tags tied to the global template trying to load but eventually it takes so long so I’m guessing it goes into a NULL. Like the below image

.I am seeing this error appear in the logs as well.

I can also change my global template to a local resource and it will load the tags getting rid of the null values but still only goes through the templates one at time. I tried to change the loading mode on the view thats open but it didnt seem to make much of a difference… To fully load a template takes 2-3 second so this adds up when I have 32 templates on the screen…

This is what I mean by loading one at a time. All the templates saying “PFP Inactive have not been loaded yet”

Did something change in how Ignition loads in 8.0.14 to 8.0.16?

Edit: I opened the template with a NULL and it says “Error Parsing/subscribing path ‘(Tag path)’ in tag() expression”

I believe it’s trying to subscribe to the tags in the remote tag path provider and it’s taking so long that they other blocks can’t load like they used too…

[pturmel]

Possibly relevant:

[BUG-13815] After Ignition upgrade to 8.0, windows are loaded with tags in error state

I think we still have the same (or similar issue) - upgraded to 8.0.15, but this has not helped. On Page swap (using the Navigation Tabstrip and using page Swap Buttons) we randomly see elements (sometimes a few and sometimes many) get stuck with the OPC_Waiting overlay (white with Tag and clock). [image] It seems to be more prevalent when swapping pages quickly, but thats only an impression. Swapping to another page and back sometimes clears all the overlays, and sometimes clears some of th…

Consider (strongly!) replacing your use of the tag() expression function with indirect bindings. It isn’t just Vision.

[Tbthomps]

I do have tag() in my expression bindings…I think you’re right and thats my issue! Thanks! I’ll give it a try and see if I can swap these to indirect tags.

UPDATE: I went back and changed the tags to indirect addressing with transforms. The loading times have improved greatly and my issues have been resolved. I’m wondering if something is wrong with the tag() in an expression statement as thats what I was using. It worked fine prior to 8.0.14

[kyle.demerath]

So would it be correct to also say then if using an Expression Structure where we had one of the values = tag(xxxx+’/CurrentValue’) we should change the Expression Structure to reference a custom tag that is an indirect binding to xxxx/CurrentValue as well? I assume tag() is slow in Expression Structure as well as Expression bindings.

Also true then?: The overhead associated with more bindings is still better than tag()?

[pturmel]

Yes. Consider that tag values update repeatedly and asynchronously, while tag paths are typically evaluated only when a Perspective view/page opens. The reduction in work in an Expression Structure that only has to evaluate tag values (from custom props) as opposed to also evaluating tag paths (that are now only part of the custom props) is a win even though there are more bindings overall.

Also consider that while an Expression Structure may be needed to deliver consistent data+config to a component, especially if a transform is used, the binding will execute when any dependency changes. If you don’t need an Expression Structure for “correctness” when depending on multiple tag values, I recommend you split it up into separate bindings.

[kyle.demerath]

Thanks for the explanation, that’s helpful. We do need the structure for correctness to run a transform when either of the values change. Specifically we have a reusable view that we parameterize and it has a number of custom property bindings. Using an expression binding was what I had done to make sure that the transform would not have issues with a race condition if one binding executed before another. Not sure if that’s clear, but if you think there’s a better way I’m all ears.

[colin.bonner]

Just to wade in here with a small bump, I believe I have run into this issue also.

I’m currently trying to spin up a dev env/gateway for our master gateway on 8.0.15 and some of my vision pages with templates having tag() expression functions that use custom property strings passed in for the tag name take literally upwards of 30 seconds to load. The project is identical on both gateways and both are on v 8.015.

The master/production server does not have this issue; load times are a second or two. The only discernible difference I can think of why, is that the dev gateway uses a remote tag provider. Testing continues…

[PGriffith]

There’s a bug (specifically in 8.0.15) with the tag() function (and/or remote tag providers, I don’t remember the exact details). I’d recommend updating - 8.0.17 should be out “soon”, if you want to get the (last) 8.0 release without upgrading to 8.1.

[tim.schultz]

Do you know if this issue affected 8.0.13 or was it specifically in 8.0.14/15?