This is all about PI SDK running from VBA in Processbook.
I have a routine that uses the PI SDK to calculate a lot of PI Values, and write them into a msFlexGrid. The routine seemed to take a long time, so I was running a timer to see where the bottlenecks were, so that I could optimise it.
The bizarre thing is that when I use breakpoints, it executes significantly faster. Yes; even stopping, having me hit "run" to move past the break-point, means that it executes about 15 seconds faster.
Execute times when I use breakpoints (two runs, times in ms)
Reading PI Data and updating Grid:2028
Cleaning up PI Interface:780
Reading PI Data and updating Grid:1856
Cleaning up PI Interface:608
Execution times when I don't use breakpoints, and just let it execute:
Reading PI Data and updating Grid:3247
Cleaning up PI Interface:16651
Reading PI Data and updating Grid:1077
Cleaning up PI Interface:16390
So: When I don't break, the "cleaning up PI interface" takes 16 seconds. When I do break (breakpoint just before), it takes less than a second.
The Cleaning Up Pip Interface code is a single line:
Set PI =Nothing
In this case, PI is a custom PI_Interface class, to behind the scenes, its running a Class_Terminate. That includes:
Private Sub Class_Terminate()
If m_PIServer.connected Then
Set m_PIServer = Nothing
Now: Reading all the data uses this PI_Interface, and I wondered if there was something going on behind the scenes that meant that the breakpoints caused enough of a delay that when I called the set PI = Nothing, the server connection was a bit more ready to close quickly, so I used Sleep(1500) for a 1.5 second delay. Nope. Didn't work.
Any suggestions as to why this might be happening? I'll try again tomorrow after a reboot, but it was pretty consistent today.