Benchmarking your code for speed - your thoughts?

[crelf]

There's some really excellent generic info about speed benchmarking code in a current OpenG discussion here :thumbup: Rather than having it die with that thread, I've created a LabVIEW Wiki page to try to capture some of it - please spend a few minutes adding your toughts to it over here.

(cross-posted to OpenG)

[Yuri33]

Is there a significant hit in execution speed if a VI is opened and executed by VI Server? If that's the case, perhaps we can establish a generalized speed test framework and help people avoid some of the pitfalls of speed testing that were shown in that other thread.

[Rolf Kalbermatter]

QUOTE (Yuri33 @ Apr 30 2008, 02:41 PM)

Is there a significant hit in execution speed if a VI is opened and executed by VI Server? If that's the case, perhaps we can establish a generalized speed test framework and help people avoid some of the pitfalls of speed testing that were shown in that other thread.

If you open the VI for Call by Reference then no there isn't much if any of a performance hit at all besides of the loading and unloading itself which of course needs to be put outside the benchmarking section. For loading and calling as task through the Run method I would expect some overhead at least for the parameter retraction for the test result through the Get Control Value method.

Rolf Kalbermatter

[LAVA 1.0 Content]

QUOTE (crelf @ Apr 29 2008, 06:33 PM)

There's some really excellent generic info about speed benchmarking code in a current OpenG discussion here :thumbup: Rather than having it die with that thread, I've created a LabVIEW Wiki page to try to capture some of it - please spend a few minutes adding your toughts to it over here.

(cross-posted to OpenG)

I took a quick look at that thread (did not read all) but I'd like to comment on the benchmark code images posted by orko.

The indicator updates from the first benchmark operation can happen in parrallel with the second benchmark code. I move all of the results calculations and display to a seq fram after all benmarking is done to make sure the second snippet's time is not obscured by the perf math and indicator updates. If times are close between to snippets I'll also double check by reversing the order, just to be sure.

Ben

[ragglefrock]

QUOTE (rolfk @ May 2 2008, 05:44 AM)

If you open the VI for Call by Reference then no there isn't much if any of a performance hit at all besides of the loading and unloading itself which of course needs to be put outside the benchmarking section. For loading and calling as task through the Run method I would expect some overhead at least for the parameter retraction for the test result through the Get Control Value method.

Rolf Kalbermatter

I believe one big difference with calling a VI by reference rather than as a subVI is that the strictly-typed VI reference doesn't contain information about inplaceness like a VI has when it calls a subVI. The main VI will have to alter the order of execution or perhaps make backups before calling a VI by reference, because it can't know what will happen to the data during the call.

[LAVA 1.0 Content]

QUOTE (ragglefrock @ May 3 2008, 10:36 AM)

I believe one big difference with calling a VI by reference rather than as a subVI is that the strictly-typed VI reference doesn't contain information about inplaceness like a VI has when it calls a subVI. The main VI will have to alter the order of execution or perhaps make backups before calling a VI by reference, because it can't know what will happen to the data during the call.

I can understand why you would believe that but I can't say that I am convinced that is true. Couldn't the type we specify when opening the VI contain enough info to allow LV to make that distinction? After all it does determine the calling convetion for the Vi being called.

Rolf et al,

Do you have any thoughts on this question?

Just wondering out loud,

Ben

[ragglefrock]

QUOTE (neB @ May 3 2008, 09:44 AM)

I can understand why you would believe that but I can't say that I am convinced that is true. Couldn't the type we specify when opening the VI contain enough info to allow LV to make that distinction? After all it does determine the calling convetion for the Vi being called.

Rolf et al,

Do you have any thoughts on this question?

Just wondering out loud,

Ben

My basis for thinking this is that the type isn't specific to one VI, but to a connector pane pattern. Two VIs with totally different inplaceness specifications could have the same connector pane and use the same type specifier. LabVIEW can't know in advance what the behavior will be, and it needs to compile the code a certain way in edit mode. I don't think it can make any adjustments when the code runs for actual inplaceness of the called VI.

[Rolf Kalbermatter]

QUOTE (ragglefrock @ May 3 2008, 11:44 AM)

My basis for thinking this is that the type isn't specific to one VI, but to a connector pane pattern. Two VIs with totally different inplaceness specifications could have the same connector pane and use the same type specifier. LabVIEW can't know in advance what the behavior will be, and it needs to compile the code a certain way in edit mode. I don't think it can make any adjustments when the code runs for actual inplaceness of the called VI.

My understanding of this is that LabVIEW does not do any optimization across VI boundaries. So Call By Reference and subVI should not make any difference. The subVI is assumed to reuse the data. If it doesn't the data is deallocated. That is why it is a good idea to wire large data always completely through a subVI (so no entering in one case and leaving only in one case but entering outside of any case and being wired through every single case frame and then to the indicator terminal outside any case again) even if you do not modify it inside the subVI.

LabVIEW only knows about nodes (built in icons usually with white yellow background) if they reuses input data or allocate a copy. For nodes reusing the data the same rules apply as for subVIs but for nodes not using the input area in any way after they have finished execution LabVIEW makes sure to order execution in such a way that those nodes get executed first if no other data dependency prevents that, in order to allow saving memory copies.

Rolf Kalbermatter

[orko]

QUOTE (neB @ May 2 2008, 04:09 AM)

I took a quick look at that thread (did not read all) but I'd like to comment on the benchmark code images posted by orko.

The indicator updates from the first benchmark operation can happen in parrallel with the second benchmark code. I move all of the results calculations and display to a seq fram after all benmarking is done to make sure the second snippet's time is not obscured by the perf math and indicator updates. If times are close between to snippets I'll also double check by reversing the order, just to be sure.

Totally agree :thumbup: