I think impact depends on scale. For just one Element i would not worry, but for thousands...
When you call refresh, if there are no changes, then you not be reloading the element, but you still will have the expense of a network call.
Instead of the AFElement.Changed event, you might have better performance using FindChangedItems method. You could get all of the objects that changes, and only refresh/load the ones you are interested in by examining the GUID.
Do you know which elements you will be querying or do you query different elements each time?
Thanks for the replies.
The number of elements to
refresh is quite low < 100 but any of them may be updated any time. Although
95% of the time there will be no changes.
Each query is different, some
queries to AF Attributes, some to collected tags as part of a formula/analysis
and some direct to archive servers.
The refresh forms a prelude to a
data fetch that is performed over the requested time range.
Thanks - Might be worth
exploring the Find ChangedItems which will run in the core code and force a
refresh if the requested Attribute forms part of a changed element, does seem
rather wasteful performing a refresh if there are no changes.
Have you considered using an AFDataPipe (from OSIsoft.AF.Data)?
Here's a good example for using pipes: How to use the PIDataPipe or the AFDataPipe
The key thing here is that a call to the server is not cheap, so it's more efficient to sign up for updates and only retrieve the changed values (in a single call).
You said that 95% of the time there will be no changes, so there's possibly a significant performance improvement there.