This depends on the context that the binding is being used in.
Yes. But in most cases it is probably negligible. If all you need is a property binding (e.g. you're not doing any work to it) then use a property binding. The real perfomance hits come when you use a property binding to get the value and then move into transforms to manipulate it when the same result can be achieved via another avenue.
This is invaluable! Thank you so much. I'll be moving this info into a document I'm building for my team!
To take this a step further, sometimes we create a non-historical, event-driven memory tag that uses multiple other tag values to form its value through an expression. We do this when we don't want to replicate this in multiple bindings across our perspective HMI. Example:
I would not believe this to degrade performance, as this will execute outside of the normal "Perspective Session" processing.
A custom session property would probably have been my first thought for this type of thing, beings as it is a non-historical tag. But I don't think that you would see any noticeable performance gain or loss.
I would expect this expression tag approach to be a win if the tag is commonly viewed by more than one client (like a common item in an application-wide docked view) all the time. It will be a performance loss for tags that are not being watched all the time. (Because the expression tag will update for every reference change, regardless.)
I normally would not do this, especially if the application size justifies a frontend/backend split.
That makes sense. In my case, it will be used in multiple areas of the app, including the front overview screen, which our operators will have open most of the time. However, it may be on a tab that would not necessarily be active all the time. In this instance, its looking at status tags that won't change too often, maybe a couple of times a day at most.