Measuring performance in compiled code

[CPeng]

I have a main vi with a sub vi. I want to compare the time the main vi is running to the time the sub vi is running. Is something like this possible?

I coded in some timing mechanisms but it's awkward. I thought the Execution State property node would do it but it doesn't distinguish between running and waiting to run.

[Ravi Beniwal]

Can you elaborate on the design? Is it just one main VI with one SubVI in it? Is the SubVI being called in a loop? Can you post the application, or a simpler version of it?

[CPeng]

The design uses modules which communicate to each other by messages. The module waits for a message in a subvi and when it receives a message it executes the command in the main vi. My goal is to see how much time is spent waiting on the next message and how much time module spends executing code. If the module is always executing code there is a problem since it will be slow responding to messages.

I attached a very stripped down version which includes my timing code (which works, I just hope there's a better way). I also included another VI which I was thinking would lead to a solution, but it doesn't work as I hoped.

Code is LV 2011.

performance statistics.zip

[Saverio]

If all you're interested in is running time of VIs then the built-in performance metrics should suffice. Go to Tools -> Profile -> Performance and Memory. This should give you a reasonable estimate to start with. If it appears that you need something more precise, then you can at least determine what it is that you need.

[CPeng]

I want the performance information programmatically on a deployed system not in a development environment.

[Ravi Beniwal]

The design uses modules which communicate to each other by messages. The module waits for a message in a subvi and when it receives a message it executes the command in the main vi. My goal is to see how much time is spent waiting on the next message and how much time module spends executing code. If the module is always executing code there is a problem since it will be slow responding to messages.

You mentioned that the modules are communicating with each other via messages. But have you separated the part of that receives and responds to the messages and the part that does the heavy lifting?

Since you are concerned about the response time from the module, I'm guessing the response you are concerned about is not the result of this heavy processing that module is doing, otherwise you'd just have to wait for it to finish, unless you want the last calculated value from it.

The example you shared has a SubVI in a Main VI loop. If the SubVI takes a long time to pass the control back to the Main VI, you should have a different loop in this Main VI that is supposed to handle messages/events.

About measuring time, it is a good idea to use the Get Date/Time in Seconds to read the current instead of the Tick Count (ms) as its value can roll over during execution, which will throw off your measurements.

[Saverio]

I want the performance information programmatically on a deployed system not in a development environment.

It really shouldn't matter that much. LabVIEW code is compiled regardless of whether you're in the development environment or the run-time environment. Are you trying to determine differences between different machines?

[CPeng]

You mentioned that the modules are communicating with each other via messages. But have you separated the part of that receives and responds to the messages and the part that does the heavy lifting?

Since you are concerned about the response time from the module, I'm guessing the response you are concerned about is not the result of this heavy processing that module is doing, otherwise you'd just have to wait for it to finish, unless you want the last calculated value from it.

The example you shared has a SubVI in a Main VI loop. If the SubVI takes a long time to pass the control back to the Main VI, you should have a different loop in this Main VI that is supposed to handle messages/events.

About measuring time, it is a good idea to use the Get Date/Time in Seconds to read the current instead of the Tick Count (ms) as its value can roll over during execution, which will throw off your measurements.

Yes I have separated the part that receives the messages from the part that does the heavy lifting. But at some point you have to get information into the loop that is doing the heavy lifting. That is what my question is centered around.

I explained the code I posted poorly. The heavy lifting is done in the loop that contains the 500ms wait. The subvi is waiting for a message. So the example code is simulating a case where the module gets a command every 1.5 seconds that takes 500ms to process. Which ends up being a 33% workload for the module.

Thanks for the tick count warning!

It really shouldn't matter that much. LabVIEW code is compiled regardless of whether you're in the development environment or the run-time environment. Are you trying to determine differences between different machines?

The reason I can not use the development environment to capture performance is because we have about 50 machines running in different conditions. I want to detect the workload of each module as it is running off site.

[Tim_S]

It really shouldn't matter that much. LabVIEW code is compiled regardless of whether you're in the development environment or the run-time environment. Are you trying to determine differences between different machines?

Executables typically do not have their block diagrams; this speeds up performance and can give you slightly different timing.

[Saverio]

Executables typically do not have their block diagrams; this speeds up performance and can give you slightly different timing.

Obviously, but as I pointed out, it was not clear the level of preciseness the OP wanted, and it was unclear (until just recently) whether the OP was trying to measure a basis timing (i.e., how well does this design work in principle), vs. the difference in timing over a large quantity of computers.