LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

overhead of a sub vi

I'm more used to text-based programming, and have only been using LabVIEW for a few months. The application I'm currently writing needs to be as fast as possible. I need to communicate with two different IEEE devices, and I'm using the GPIB Write and GPIB Read built into LabVIEW (7.1 anyways). The question I'm asking is this: would I see any change in performance if I were to put these read and writes into a sub vi, as opposed to running in the top level? My only fear is that there would be some sort of memory overhead for using calling a sub vi, executing it, and then returning to the top-level, that would cause a lull in performance. In a text-based language I know that calling a subroutine has virtually no overhead, but being unfamiliar with LabVIEW, I'm not sure if there is one associated with calling a sub vi. Thanks for any help.

Geoff
0 Kudos
Message 1 of 2
(2,202 Views)
LabVIEW does show a small performance "hit" in sub-vi's, but running it in the top level vi, presumably the user interface level introduces the performance hit of running in the user interface thread. GPIB communication is not terribly fast, from the point of view of modern host computers, this is what LabVIEW users have been doing (GPIB in sub-vi's) since the beginning of LabVIEW. So putting your GPIB communications stuff in sub-vi's is definitely the way to go. There are other LabVIEW constructs that can cause slow downs in performance, particularly in the user interface, but we will address those as you find them.


P.M.
Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 2 of 2
(2,198 Views)