57.LabVIEW 程序的内存优化 2 - 子 VI 的优化.docVIP

　　LabVIEW 程序的内存优化 2 - 子 VI 的优化 　　1. 子 VI 参数的缓存重用 　　数据在子 VI 间传入传出，如果程序设计的好，可以做到缓存重用，使得数据在主 VI 和子 VI 中都不发生拷贝，提高程序的效率。 　　我们先来看一下图1所示的 VI。打开 ToolProfileShow Buffer Allocations 工具查看一下这个 VI 中内存分配的情况，会发现在代码的加法函数处有一个黑点。这个黑点说明程序在这里有分配了一块内存，这个内存是用来存储加法运算结果的。s 　　 　　图1：控件不与接线器相连时，加法处有内存分配 　　为什么加法函数在这里不做缓存重用呢?利用其中一个加数的内存空间来保存计算结果。 　　当这个 VI 运行的时候，图2中，加数 Numeric 的数据是由 VI 前面板的控件提供的。如果用户不修改控件的值，每次 VI 运行，这个数值应该是保持不变的。如果加法函数在这里做缓存重用，加数或者说它对应的控件中的数据，就会在加法运算执行后被修改。这样程序就会出现逻辑上的错误。 　　所以把一个这样的控件联在 LabVIEW 的运算节点上，运算节点是不能重用控件的数据内存的。同样的道理，链接一个常量到运算节点上，节点同样不能做缓存重用。在子 VI 中，没有连到接线器上的输入控件就相当与一个常量。 　　但是，如果我们让 VI 上的控件与 VI 的接线器(Connector Pane)相连，情况就不一样了。入图2所示，把三个控件连到接线器上，程序中加法节点上那个黑点就消失了，不再为运算结果分配新的内存。 　　 　　图2：控件不与接线器相连时，加法处有内存分配 　　这是因为，当输入控件与接线器连接后，LabVIEW 就认为这个输入值应当是由子 VI 的调用者(父 VI)提供的：连到接线器上，逻辑上，这个输入控件就不再是常量，而是一个输入变量了。既然是输入变量，子 VI 不需要记住输入的数据共下次调用时使用，因此可以把新产生的数据放在输入参数所在的内存，做到缓存重用。 　　你可能在想，这个输入参数的内存不一定可以被修改吧，万一它的数据还要在父 VI 中被其它节点使用呢? 　　子 VI 是不需要考虑这点的，输入数据的数据被修改肯定是安全的，这一点是由父 VI 来保证的。如果输入数据不能被修改，父 VI 会把传入的数据拷贝一份再传到子 VI 中去。 　　比如图3中的程序，它所调用的子 VI 就是图2中那个 VI。由于与它的第一个输入参数相连的是一个常量，而常量的值是不能被改变的。所以 LabVIEW 要把这个常量的值复制一份，再传到子 VI 中去，以保证子 VI 中的运算节点可以做缓存重用。 　　 　　图3：父 VI 中的数据拷贝 　　如果图3中的父 VI，他也使用与接线器相连的输入控件为子 VI 提供输入参数，则 LabVIEW 会知道，父 VI 的这个数据是由再上一层 VI 提供的，这里也不需要需要做数据拷贝。这样，这个 VI 就也做到了缓存重用。设计合理，参数在传递多个深度后都不需要开辟新内存的。 　　从上面的说明中，还可以发现一个问题。就是，有时候子 VI 的改动，会影响父 VI 的行为，比如是否为传入子 VI 的数据做个拷贝等等。有时候我们发现改动了一个子 VI，它的父 VI 也需要重新保存，就是由这个原因引起的。 　　2. 输入输出参数的排布 　　在子 VI 的程序框图上，不论代码有多复杂，有多少嵌套的结构，控件终端最好按照这样的方式排布：所有输入参数(控制型控件的终端)都放在代码的最左端排成一列;所有的输出参数(显示型控件的终端)都放在代码。比如图4中的代码的风格就比较好。 　　 　　图4：控件终端整齐的排列在程序框图左右两端 　　这首先是为了保证程序有良好的可读性。我们在阅读 LabVIEW 代码的时候总是按照从左到右的顺序，所有的参数都排布在一起，我们就可以以数据线为线索，轻易的找的数据被读写的地方。其次，这种风格的 VI，在效率上也比较优化。 　　对于一个输入参数(控制型控件的终端)，如果把它放程序代码的最左侧，所有结构的外面，程序在运行这个子VI之前，就可以得到这个参数的确切值了。 　　但是，如果这个终端是在代码的某个结构中的，在某一结构的内部，那么LabVIEW必须在运行到这一结构内部的时候，才可以去读这个参数的值，否则可能会引起罗技上的错误。比如说，一个控制型控件的终端是在一个循环的内部，开始时它的值是x。在运行到第n次循环之前，这个终端对应的前面板上的控件被人改为一个新的数值y。那么逻辑上，在执行第n次循环之前，每次用到这个参数时，它的值要保持为x，而在第n次循环的时候，又要使用它的新值y。这样的数据所在的内存，LabVIEW 显然是不能将其重用的，否则下次循环再读它的时候，