I’ve been quite happy with my testing of AFSDK 2.5 CTP2. I work in a big AF shop so the emphasis on my tests has asset-centric. However, my company does have some tag-centric PISDK applications and I’ve recently tested out the feasibility of using AFSDK 2.5 for tag-centric apps. Obviously there was going to a syntax change for some commands, plus I wanted to gauge performance. Keep in mind that when I mention AFSDK for this particular post, I am referring to the OSIsoft.AF.PI namespace for counterparts to PISDK objects and methods.
I have mixed feelings on some of the new commands. To connect to a PIServer you must connect to a PISystem first. That just seems awkward for some reason, but it’s such trivial code that it's really no big deal. I do appreciate that its now PIServer in AFSDK, contrasted to the very generic sounding Server in PISDK. And when you’re fetching values from PI it’s no longer PIValues being returned but rather AFValues. I had a slight brain freeze with that last one but came to appreciate it because I like the constructor methods with AFValues and AFTime far better than their PISDK counterparts.
One big syntax difference was for anything fetching values based on a time range. The PISDK methods usually required separate parameters for StartTime and EndTime. The new AFSDK methods require an AFTimeRange object. What I found myself doing for my own methods was overloading it to accommodate both method signatures.
As far as features, I’ve got to correct a misconception I’ve had about Rich Data Access in 2.5. I was under the impression that you could not delete data as there is no equivalent RemoveValues method in AFSDK. While it is true that this convenience method is missing, it is false that you can’t delete PI data using AFSDK. Using the RDA UpdateValues method with the AFUpdateOption.Remove flag will remove values, or at least attempt to do so based on your user credentials ;-).
The other nice features of AFSDK is what we’ve all read about since CTP1: managed .NET code and objects that don’t use COM so now I don’t have to worry about marshaling, etc. Whereas PISDK could be sluggish in MTA threads, AFSDK is quite happy in MTA.
A feature missing from 2.5 but slated for 2.6 is an AF equivalent of the PIAsynchStatus object. While it would be nice to have, it does add more complexity to an application. Don’t get me wrong – I’m a big fan of PIAsynchStatus but in some instances it can actually make your application run slower. It would be quite useful to have in the toolbox but is something I use in less than 20% of my PISDK applications. I can’t write any application with it that I can’t also write without it.
Since this is a pre-release product, I’m not going to publish any hard numbers but what I will say is that I do like the speed I’ve seen so far. Would I like it to be faster? Absolutely. Then again, I want the PISDK to be faster too! But for what I consider to be an impending first release of managed, COM-less objects, I think performance is quite acceptable. Or as one colleague said “It’s pretty durn fast.” For those that don’t speak Southern, ‘pretty durn fast’ is a very good thing. There are some commands where PISDK performs ever so slightly faster than AFSDK – though I would say it is insignificantly faster because within a blink of an eye is still a within a blink of an eye . Yet there are some commands that perform a wee bit faster – that is to say not so insignificant but just a smidgen noticeably faster.
There was one command where AFSDK was quite faster than PISDK: fetching a large collection of PIPoint objects or a PointList. When testing a small set of 200 or so tags, PISDK was slightly faster. But when fetching my entire tag collection of 35,000+ tags, AFSDK was noticeably faster. Over a series of several tests, PISDK would take between 3 and 5 seconds to fetch all 35K tags, whereas AFSDK would do the same thing in half that time.
ONE PERSON’S OPINION
Based on the performance I’ve seen and the features of AFSDK, once AF 2.5 is released into production I would not hesitate to write a tag-centric application in AF 2.5. Not only because this is the strategic direction of where OSIsoft is heading, but just in case you ever need to promote it to be asset-based, my application would already be in AFSDK. For example if I’m just doing tag-centric processing, I wouldn’t be concerned about UOM’s. But what if my needs suddenly changed and I needed to worry about UOM data conversions of my PI data? This would be an easy transition if my formerly tag-centric application was based on AFSDK 2.5.
That’s just one person’s opinion. And that’s all for now.