试谈LabVIEW程序的内存优
LabVIEW 程序的内存优化1
一. VI 在内存中的结构
打开一个VI的属性面板(VI Properties)，其中的“内存使用”(Memory Usage)是用来查看这个VI内存占用情况的。它显示了一个VI内存占用所包含的四个主要部分：前面板、框图、代码和数据，以及这四个部分的总和。但在打开一个VI时，这四段内容并不是同时都会被LabVIEW调入内存的。
当我们打开一个主VI时，主VI连同它的所有子VI的代码和数据段都会被调入内存。由于主VI的前面板一般情况下是打开的，它的前面板也就同时被调入内存。但是此时主VI的框图和子VI的前面板、框图并没有被调入内存。只有当主动查看主VI的框图或是打开子VI的前面板和框图时，它们才会被调入。
基于LabVIEW的这种内存经管的特性，我们在编写VI的时候可以通过以下方法来优化LabVIEW程序的内存使用。
第一，把一个复杂VI分解为数个子VI。子VI的使用会增添额外的前面板和框图的空间，但并不增添额外的代码和数据空间。由于程序运行时只有代码和数据被调入内存，因此使用子VI不会占用额外的内存。使用子VI的好处还在于当子VI运行结束时，LabVIEW可以及时收回子VI的数据空间，从而改善了内存的使用效率。
第二，在没有必要时不要设置子VI的重入(Reentrant)属性。重入型VI每次运行时都会对自己使用的数据生成一个副本，这增加了内存开销。
第三，主VI的面板通常就是用户界面，需要显示给用户。但是要尽量避免开启子VI前面板。比如，在子VI中使用与其前面板控件有关的属性节点(Property Node)会导致它的前面板被调入内存中，增加了内存开销，所以要尽量避免在子VI中使用主面板控件的属性节点来设置控件的值，而可以用局部变量等方法来
替代。
第四，我们可以放心地在VI 的前面板(对于非界面VI)和框图里添加图片，注释等信息来帮助你编写、维护LabVIEW程序，这些帮助信息不会在VI运行时占用内存。
二. 内存泄漏。
LabVIEW与C语言不同，它没有任何分配或释放内存的语句，LabVIEW可以自动经管内存，在适当的时候分配或收回内存资源[1]。这样就避免了C语言中常见的因为内存经管语句使用不当而引起的内存泄漏。
在LabVIEW中一般只有一种情况能够引起内存泄漏，即你打开了某些资源，却忘记了关闭它们。比如，在对文件操作时，我们需要先打开这个文件，返回它的句柄。随后如果忘记了关闭这个句柄，它所占用的内存就始终不会被释放，从而产生内存泄漏。LabVIEW中其它带有打开句柄的函数或VI也会引起同样的问题。
由于内存泄漏是动态产生的，我们无法通过VI的属性面板来查看，但可以通过Windows自带的任务经管工具来查看LabVIEW程序内存是否有泄漏。也可以使用LabVIEW的Profile (Tools>>Advanced>>Profile VIs)工具来查看某个VI 运行时内存的分配情况。
三. 缓存重用
LabVIEW程序主要是数据流驱动型的。数据传递到不同节点时往往需要复制一个副本。这是LabVIEW为了防止数据被节点改变引起错误所做的一种数据保护措施。只有当目标节点为只读节点，不可能对输入数据作任何更改时，才不在这些节点处做备份。例如，数组索引节点(Index)是不会改变数组值的，LabVIEW 在这里就不为输入数组做备份。对于加减法运算等肯定改变输入数据的节点，LabVIEW往往需要对输入或输出数据作备份。有些LabVIEW程序，比如涉及到大数组运算的程序，内存消耗极大。其主要原因就是LabVIEW在运算时为数组数据生成了过多的副本。
实际上很多LabVIEW节点是允许使用缓存重用的，这类似C语言调用子函数所使用的地址传递。通过合理设计和使用缓存重用节点，可以大大优化LabVIEW程序的内存使用。使用LabVIEW 7.1的Tool>>Advanced>>Show Buffer
Allocations (LabVIEW 8.0 之后使用Tool>>Profile>>Show Buffer Allocations)工具可以在VI框图中查看缓存的分配情况。打开该工具，凡是在框图中有缓存分配的地方，都会显示出一个黑点。
下面是几个最常用节点的实验结果。LabVIEW节点众多，不可能一一列举，文中未提及的节点读者在编程时自己可以尝试。
1. 一般顺序执行VI中的运算节点
图1：简单的顺序执行程序
如图1所示，程序对一个常量加1，然后将结果输出。
“+1”节点输出端有一个黑点，表示LabVIEW在此处开辟了一个缓存用于保存运算结果。
其实完全可以利用输入数据的内存空间来保存这个运算结果。我们可以通过如下的方法来告知LabVIEW编译器，在此运算节点处重用输入数据的内存空间。
首先，用一个控制型数值控件代替图中的数值常量，然后分别将VI中的两个控件与VI的接线器(Connector Pane)相连。
图2：实现缓存重用
图2是经过我们优化后的VI，LabVIEW在“+1”节点处没有开辟新的缓存。LabVIEW中其它运算节点也有类似的性质。
2. 移位寄存器(Shift Register in the Loop Structure)
移位寄存器是LabVIEW内存优化中最为重要的一个节点，因为移位寄存器在循环结构两端的接线端是强制使用同一内存的。这一特性可以被用来通知LabVIEW在编译循环内代码时，重用输入输出缓存。
图3：对数组进行数值运算的顺序执行程序
让我们分析一下图3所示的程序：它首先构造了一个数组，然后对这个数组进行了几次数学运算。每一步运算，LabVIEW都要开辟一块缓存用以保存运算结果的副本。打开VI属性面板上的内存使用，可以看到这个VI大约会占用2.7M 的内存空间。其实这些副本都是不必要的，每一步运算的结果都可以被保存到输入数据的内存空间。我们可以把所用的运算节点都放到一个子VI中，然后利用上一段提到的方法，使子VI中的代码缓存重用。还有一种方法，利用移位寄存器也可以实现缓存重用。
图4：利用移位寄存器实现缓存重用
如图4，我们可以将运算代码放在一个只运行一次的循环结构内，由于运算部分的输入和输出都与移位寄存器相连，这就相当于通知了LabVIEW，在运算的输入输出需要使用同一块缓存。因而，LabVIEW 不再为每一步运算开辟新的缓存而是直接利用输入数据的缓存保存结果。打开VI属性面板上的内存使用，可以查看到这个VI的内存占用已经减少到了原来的六分之一。
在LabVIEW 8.5 中，有了一个新的结构——缓存重用结构，专门用于优化代码的内存使用。可以不必再使用移位寄存器来完成这项工作了。
3. 库函数调用节点(Call Library Node)
以传递整型参数为例：在参数配置面板，我们可以选择值传递(Pass Value)或选择指针传递(Pass Pointer to Value)。
当选择了值传递时，库函数调用节点是不会改变该参数的内容的。如果我们
在该库函数调用节点参数的左侧接线端引入输入数据，在输出端引出输出参数，那么输出数据其实是直接由输入数据引出的，LabVIEW不会在这个节点处开辟缓存。
在指针传递方式时，LabVIEW则认为传入的数据会被改变。如果输入数据同时还要发往其它节点，LabVIEW会在此处开辟缓存，为输入数据作一个副本。选用指针传递方式，库函数调用节点的每一对接线端也同样是缓存重用的。就是说，库函数调用节点的输出值是直接存放在输入值的缓存空间的。
如果一个参数只用作输出，我们通常会在库函数调用节点的输入接线端为它建立一个输入常数，这个常数的地址空间并不能直接被利用，它只是为库函数调用节点开辟的缓存而设置的初始值。不接输入常数，LabVIEW也会为此参数开辟一块缓存。但是，这样每次传入的参数值都会有变化。例如图5，库函数调用节点调用的函数功能是为把输入的值加1，然后输出。图5-a中的输出值永远都是1，而图5-b，每次运行输出结果都会比前次增加1。这是因为库函数调用节点每个指针传递的参数的输入输出用的是同一块缓存，即每次运行输入值是上回的输出值。
图5：库函数调用节点
我们可以利用图5-c的例子证明LabVIEW某些节点是缓存重用的。每次运行5-c的例子，输出结果都会比前次增加2。这是因为示例中的参数接线端以及“+1”节点的输入输出端所使用的都是同一缓存。
如果，库函数调用节点中某个参数只有输入链进去，没有输出。那么，LabVIEW 是假设你调用的函数不会修改这个参数的。LabVIEW 不会为这个数据做拷贝，它会重用这个数据的缓存。但如果你调用的函数修改的这个数据，你的程序就会面临这样一个潜在的危险：这个数据可能被程序其它部分的代码使用了，在那里，你看不出这个数据有任何被改动的地方，但它在运行时却不是你期
望的数值。因为这个数据所在的缓存，被程序其它一个地方的一个库函数调用节点给重用了，而这个节点又偷偷摸摸的修改了它。
在图5中的示例中，如果库函数调用节点输出的参数是个数组或者字符串，那么就必须为它相对应的输入端联入一个与输出数据大小一致的数组或字符串。否则，LabVIEW无法知道输出数据的大小，而使用默认分配的缓存空间很容易出现数组越界错误。
四. 小结
缓存重用是LabVIEW内存优化的最重要的一个环节。精心设计的LabVIEW 程序可以大大节约内存的占用，提高运行效率。但是，在编写完程序后再按照程序优化的技巧回头去优化一段已有的程序，这并不是一个好的编程方法。我们应该先熟悉理解优化的方法，在以后的开发过程中自然而然地将它们应用在编程中。
参考文章：
LabVIEW 程序中的线程 1
LabVIEW 程序的内存优化 2 - 子VI 的优化
LabVIEW 是编译型语言还是解释型语言
我和LabVIEW
pdf 格式文档下载
其他技术文章