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

LabVIEW程序的内存优化2-子VI的优化1.子VI参数的缓存重用数据在子VI间传入传出，如果程序设计的好，可以做到缓存重用，使得数据在主VI和子VI中都不发生拷贝，提高程序的效率。我们先来看一下图1所示的VI。打开ToolProfileShowBufferAllocations工具查看一下这个VI中内存分配的情况，会发现在代码的加法函数处有一个黑点。这个黑点说明程序在这里有分配了一块内存，这个内存是用来存储加法运算结果的。s图1：控件不与接线器相连时，加法处有内存分配为什么加法函数在这里不做缓存重用呢?利用其中一个加数的内存空间来保存计算结果。当这个VI运行的时候，图2中，加数Numeric的数据是由VI前面板的控件提供的。如果用户不修改控件的值，每次VI运行，这个数值应该是保持不变的。如果加法函数在这里做缓存重用，加数或者说它对应的控件中的数据，就会在加法运算执行后被修改。这样程序就会出现逻辑上的错误。所以把一个这样的控件联在LabVIEW的运算节点上，运算节点是不能重用控件的数据内存的。同样的道理，链接一个常量到运算节点上，节点同样不能做缓存重用。在子VI中，没有连到接线器上的输入控件就相当与一个常量。但是，如果我们让VI上的控件与VI的接线器(ConnectorPane)相连，情况就不一样了。如图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显然是不能将其重用的，否则下次循环再读它的时候，数据就不正确了。如果这个终端是在所有结构之外，LabVIEW则可以根据数据线的链接，明确的判断出在某一节点执行完之后，程序再也不需要用到这个参数的值了，那么LabVIEW就可以重用它所在的内存，以避免开辟新内存，拷贝数据等操作。这样就提高了程序的内存效率。对于一个输出参数(显示型控件的终端)，如果它位于某个条件结构的内部，LabVIEW就要考虑，程序有可能执行不到这个条件。LabVIEW就会多添加一些代码来处理这种情况，当VI没有运行到这个条件时，要给输出参数准备一个默认值。把这个终端移到所有结构之外，就可以省去这部分LabVIEW自动添加上去的工作和，稍微提高一点效率:)3.良好的数据流结构可以优化程序内存效率先看一个程序:图5：程序中没有必要的数据线分枝图5的程序只是一个演示，不必追究它到底实现了什么功能。图中的左半部分是主VI，在这个VI中对输入的数组数据Array进行了两次操作：一次使用subVI“MySearch”;另一次使用了数组排序函数。图5的右半部分是subVI“MySearch”的程序框图。需要注意的是，主VI上Sort1DArray函数那里有个黑点(这个黑店靠近黄色方块的中心，这里看不太清楚，和图6对比一下，就可以发现了)，说明这里做了一次内存分配。这是因为Array的数据被同时传递到了“MySearch”和“Sort1DArray”两个节点进行处理。这两个操作可能会同时进行，LabVIEW为了安全(两个操作对数据的改动不能相互影响，不能同时对一块内存进行读写)，就必须为这两个节点准备两份数据在两份内存中。所以在“MySearch”和“Sort1DArray”两个节点中，如果一个节点用了原来Array的内存，另一个节点就需要拷贝一份数据给自己用。不过，如果看一下“MySearch”的程序框图，它其实没有对Array数据进行任何改动，主VI完全没有比要给“Sort1DArray”开辟一块新内存。我们只要对程序稍作改动，就可以对此进行优化。图6是改进后的程序：图6：符合数据流风格的主VI在改进后的程序中，Array数据首先传入subVI“MySearch”，然后又传出来，继续传给“Sort1DArray”函数。这样子看上去好像数据要多到子VI中转一圈，但实际上，由于子VI中Array输入输出是缓存重用的，实际上相当于只是把数组数据的引用传给了子VI，效率是相当高的。而在主VI中，执行“Sort1DArray”时，LabVIEW知道输入数据现在是这个节点专用的，改了他也是安全的，于是也可以缓存重用。图六中，“Sort1DArray”上的那个小黑点就消失了。图6中的主VI，它的优点首先是符合数据流的风格。一个主要的数据从左到右，流经每个节点。这样的程序非常容易阅读和理解。LabVIEW也更容易对这样的代码进行优化，所以这样风格的程序通常效率也比较高。有的时候，利用LabVIEW的自动多线程特性，书写并行代码，对程序效率有利。比如，程序中某一部分的代码需要较长时间的计算或者读写时间的情况。但是并不是任何时候并行执行都好。并行书写的程序不易理解，容易出错，多线程运行也会带来额外的开销。像图5、图6中的程序，数据量较大，但是并没有比较耗时的运算操作，或数据读写操作，这样的程序，串行运算比并行效率更高。