4 Replies Latest reply on Mar 10, 2015 5:02 PM by Rick Davin

    Attribute.PIPoint performance issues


      I am trying to detect whether or not an AF Attribute has a PIPoint associated with it using the following code:


      foreach(AFAttribute attribute in element.Attributes){
                if(attribute.PIPoint != null){                   // This line is slow
                     string pitag_name = attribute.PIPoint.Name; // This line is slow
           } catch (Exception e) {
                // Handle error thrown when no PIPoint exists

      The problem here is twofold. One is that this method of detecting a PIPoint's existence takes 2-3 seconds. Then reading the name by calling the Attribute.PIPoint.Name property takes 2-3 seconds. And further annoyance is caused by having to use a try/catch to catch the error that is thrown when a PIPoint does not exist.


      My main issue is performance. This has to be done quickly and, if possible, more neatly (i.e. without the try/catch). Is there a better way to do this?

        • Re: Attribute.PIPoint performance issues
          David Hearn

          You can load all the AFAttributes that you want to check for a PIPoint into an AFAttributeList and then call the AFAttributeList.GetPIPoint method. This will load the PIPoint for each associated AFAttribute in bulk.

            • Re: Attribute.PIPoint performance issues

              Hi David, thanks for the advice.


              I performed a test with your suggestion and the performance did not differ. That method appears to be shifting the load rather than reducing it; the fundamental problem of it taking several seconds to load the PIPoint object remains.


              I do not actually need the PIPoint object. All I need is a way to detect whether or a not a PIPoint exists and the name of said PIPoint.

            • Re: Attribute.PIPoint performance issues

              Found a solution by reading the config string of an AF Attribute, which contains the PIPoint name at the end.

              • Re: Attribute.PIPoint performance issues
                Rick Davin

                Glad you found a solution.  For the sake of posterity, I offer some related links from the olden days of vCampus:


                RawPIPoint in a Custom AF Data Reference Plugin (Dec 29, 2011)


                A good discussion.  Chris Manhard provides news that custom DR's can expose their own public RawPIPoint property but that RawPIPointPath is exclusive to OSIsoft's PIPoint data reference. Sure the RawPIPoint object is for older PISDK but the RawPIPointPath may still be the fastest way to extract the tag name.


                Simplest method to get the PI tag name for an attribute (Feb 21, 2012)


                Another good discussion from many about RawPIPoint and RawPIPointPath.  My post on Feb 22, 2012 offers some performance timings.  Note that RawPIPointPath is only available for the PIPoint data reference but it is very fast when all you care about is extracting the tag name.


                Blog post: Sometimes, it the small things that matter (Nov 7, 2012)


                If you only want to see if an attribute uses the PIPoint data reference, in this brief blog I provide the optimal code with some shocking performance timings.  This does not fetch a tag name, nor parse the config file, nor fetch anything from a PI server.  It simply checks to see if the PIPoint data reference is associated to a given attribute.  Also, since it's the small thing that matters, I am embarrassed to see that I left the original apostrophe+s out of "it's".  No wait.  I am quite sure that it was omitted when they transferred blogs from vCampus to DevClub.  I've never made a typo in my wife.


                The things to keep in mind for others reading this one day:

                • Are you using custom DR's that set PIPoint or RawPIPoint, or are you exclusively using the PIPoint data reference?  See first link above.
                • Do you want to extract just the PI tag name?  See 2nd link.
                • Do you only want to check if the PIPoint DR is being referenced?  See 3rd link.