《LabVIEW程序的内存优化之子VI的优化》由会员分享，可在线阅读，更多相关《LabVIEW程序的内存优化之子VI的优化（7页珍藏版）》请在金锄头文库上搜索。
1、LabVIEW 程序的内存优化 2 - 子 VI 的优化1. 子 VI 参数的缓存重用数据在子 VI 间传入传出，如果程序设计的好，可以做到缓存重用，使得数据在主 VI 和子 VI 中都不发生拷贝，提高程序的效率。我们先来看一下图1所示的 VI。打开 ToolProfileShow Buffer Allocations 工具查看一下这个 VI 中内存分配的情况，会发现在代码的加法函数处有一个黑点。这个黑点说明程序在这里有分配了一块内存，这个内存是用来存储加法运算结果的。s图1：控件不与接线器相连时，加法处有内存分配为什么加法函数在这里不做缓存重用呢?利用其中一个加数的内存空间来保存计算结果。当
2、这个 VI 运行的时候，图2中，加数 Numeric 的数据是由 VI 前面板的控件提供的。如果用户不修改控件的值，每次 VI 运行，这个数值应该是保持不变的。如果加法函数在这里做缓存重用，加数或者说它对应的控件中的数据，就会在加法运算执行后被修改。这样程序就会出现逻辑上的错误。所以把一个这样的控件联在 LabVIEW 的运算节点上，运算节点是不能重用控件的数据内存的。同样的道理，链接一个常量到运算节点上，节点同样不能做缓存重用。在子 VI 中，没有连到接线器上的输入控件就相当与一个常量。但是，如果我们让 VI 上的控件与 VI 的接线器(Connector Pane)相连，情况就不一样了。如
3、图2所示，把三个控件连到接线器上，程序中加法节点上那个黑点就消失了，不再为运算结果分配新的内存。图2：控件不与接线器相连时，加法处有内存分配这是因为，当输入控件与接线器连接后，LabVIEW 就认为这个输入值应当是由子 VI 的调用者(父 VI)提供的：连到接线器上，逻辑上，这个输入控件就不再是常量，而是一个输入变量了。既然是输入变量，子 VI 不需要记住输入的数据供下次调用时使用，因此可以把新产生的数据放在输入参数所在的内存，做到缓存重用。你可能在想，这个输入参数的内存不一定可以被修改吧，万一它的数据还要在父 VI 中被其它节点使用呢?子 VI 是不需要考虑这点的，输入数据的数据被修改肯定是
4、安全的，这一点是由父 VI 来保证的。如果输入数据不能被修改，父 VI 会把传入的数据拷贝一份再传到子 VI 中去。比如图3中的程序，它所调用的子 VI 就是图2中那个 VI。由于与它的第一个输入参数相连的是一个常量，而常量的值是不能被改变的。所以 LabVIEW 要把这个常量的值复制一份，再传到子 VI 中去，以保证子 VI 中的运算节点可以做缓存重用。图3：父 VI 中的数据拷贝如果图3中的父 VI，他也使用与接线器相连的输入控件为子 VI 提供输入参数，则 LabVIEW 会知道，父 VI 的这个数据是由再上一层 VI 提供的，这里也不需要做数据拷贝。这样，这个 VI 就也做到了缓存重用
5、。设计合理，参数在传递多个深度后都不需要开辟新内存的。从上面的说明中，还可以发现一个问题。就是，有时候子 VI 的改动，会影响父 VI 的行为，比如是否为传入子 VI 的数据做个拷贝等等。有时候我们发现改动了一个子 VI，它的父 VI 也需要重新保存，就是由这个原因引起的。2. 输入输出参数的排布在子 VI 的程序框图上，不论代码有多复杂，有多少嵌套的结构，控件终端最好按照这样的方式排布：所有输入参数(控制型控件的终端)都放在代码的最左端排成一列;所有的输出参数(显示型控件的终端)都放在代码。比如图4中的代码的风格就比较好。图4：控件终端整齐的排列在程序框图左右两端这首先是为了保证程序有良好的
6、可读性。我们在阅读 LabVIEW 代码的时候总是按照从左到右的顺序，所有的参数都排布在一起，我们就可以以数据线为线索，轻易的找的数据被读写的地方。其次，这种风格的 VI，在效率上也比较优化。对于一个输入参数(控制型控件的终端)，如果把它放程序代码的最左侧，所有结构的外面，程序在运行这个子VI之前，就可以得到这个参数的确切值了。但是，如果这个终端是在代码的某个结构中的，在某一结构的内部，那么LabVIEW必须在运行到这一结构内部的时候，才可以去读这个参数的值，否则可能会引起逻辑上的错误。比如说，一个控制型控件的终端是在一个循环的内部，开始时它的值是x。在运行到第n次循环之前，这个终端对应的前面
7、板上的控件被人改为一个新的数值y。那么逻辑上，在执行第n次循环之前，每次用到这个参数时，它的值要保持为x，而在第n次循环的时候，又要使用它的新值y。这样的数据所在的内存，LabVIEW 显然是不能将其重用的，否则下次循环再读它的时候，数据就不正确了。如果这个终端是在所有结构之外，LabVIEW 则可以根据数据线的链接，明确的判断出在某一节点执行完之后，程序再也不需要用到这个参数的值了，那么 LabVIEW 就可以重用它所在的内存，以避免开辟新内存，拷贝数据等操作。这样就提高了程序的内存效率。对于一个输出参数(显示型控件的终端)，如果它位于某个条件结构的内部，LabVIEW 就要考虑，程序有可能
8、执行不到这个条件。LabVIEW 就会多添加一些代码来处理这种情况，当 VI 没有运行到这个条件时，要给输出参数准备一个默认值。把这个终端移到所有结构之外，就可以省去这部分 LabVIEW 自动添加上去的工作和，稍微提高一点效率:)3. 良好的数据流结构可以优化程序内存效率先看一个程序:图5：程序中没有必要的数据线分枝图5 的程序只是一个演示，不必追究它到底实现了什么功能。图中的左半部分是主 VI，在这个 VI 中对输入的数组数据Array进行了两次操作：一次使用 subVI“My Search” ;另一次使用了数组排序函数。图5 的右半部分是 subVI“My Search”的程序框图。需要
9、注意的是，主 VI 上 Sort 1D Array 函数那里有个黑点(这个黑店靠近黄色方块的中心，这里看不太清楚，和图6对比一下，就可以发现了)，说明这里做了一次内存分配。这是因为Array的数据被同时传递到了“My Search”和“Sort 1D Array”两个节点进行处理。这两个操作可能会同时进行，LabVIEW 为了安全(两个操作对数据的改动不能相互影响，不能同时对一块内存进行读写)，就必须为这两个节点准备两份数据在两份内存中。所以在“My Search”和“Sort 1D Array”两个节点中，如果一个节点用了原来Array的内存，另一个节点就需要拷贝一份数据给自己用。不过，如果
10、看一下“My Search”的程序框图，它其实没有对Array数据进行任何改动，主VI完全没有比要给“Sort 1D Array”开辟一块新内存。我们只要对程序稍作改动，就可以对此进行优化。图6 是改进后的程序：图6：符合数据流风格的主VI在改进后的程序中，Array 数据首先传入subVI“My Search”，然后又传出来，继续传给“Sort 1D Array”函数。这样子看上去好像数据要多到子VI中转一圈，但实际上，由于子VI中Array输入输出是缓存重用的，实际上相当于只是把数组数据的引用传给了子VI，效率是相当高的。而在主 VI 中，执行“Sort 1D Array”时，LabVIE
11、W 知道输入数据现在是这个节点专用的，改了他也是安全的，于是也可以缓存重用。图六中，“Sort 1D Array”上的那个小黑点就消失了。图6 中的主 VI，它的优点首先是符合数据流的风格。一个主要的数据从左到右，流经每个节点。这样的程序非常容易阅读和理解。LabVIEW 也更容易对这样的代码进行优化，所以这样风格的程序通常效率也比较高。有的时候，利用 LabVIEW 的自动多线程特性，书写并行代码，对程序效率有利。比如，程序中某一部分的代码需要较长时间的计算或者读写时间的情况。但是并不是任何时候并行执行都好。并行书写的程序不易理解，容易出错，多线程运行也会带来额外的开销。像图5、图6中的程序，数据量较大，但是并没有比较耗时的运算操作，或数据读写操作，这样的程序，串行运算比并行效率更高。
