I recently posted some timing info in another thread and gave incorrect data. It seems that I once again fell victim to performance caching. I was comparing formulas and custom data references to the PI Point DR, and it erroneously showed a custom data reference as being almost 4 times slower than the PI Point DR. I am relieved to say this is not true.
Where did I go wrong? It seems that I made a special check for a PI Point DR, and if found, I made a call to the RawPIPoint object to issue report some info. Later when I issued the GetValues call, it went very fast. That's because the overhead of invoking the RawPIPoint was already performed and not included in the GetValues timings.
I've now corrected that and I made my test case extremely simple or down-right trivial. I'm not performing any UOM conversion or rounding of any number. All I am doing is echoing another PI Point attribute. It's so simple I even compared a VB.NET version to a C# version of the custom data reference.
Running on my laptop with AF Server 126.96.36.19948, my raw PI Point has 85265 values, all of them good. The attribute with the PI Point DR is named 'Raw Temperature". All my attributes are Single (Float32) with a UOM of degree Farenheit.
The echo Formulas are quite simple as well. One is called Formula-A. That would be A for 'As-is'. Keep in mind, I said this was all clean data. Every value tested was a good number. Let's face it, though: that would be rarely the case. Instead you need to pad the calculation with a badval check. Let's call this Formula-B, where B of for 'Badval Check'.
A=Raw Temperature;[ A ]
A=Raw Temperature;[if badval(A) then NaN else A]
All I can saw is, it takes a big man to admit when he's wrong, and I am such a big man.