LabVIEW程序的内存优化之子VI的优化

HYPERLINKLabVIEW程序的内存优化2-子VI的优化　　1.子VI参数的缓存重用　　数据在子VI间传入传出，如果程序设计的好，可以做到缓存重用，使得数据在主VI和子VI中都不发生拷贝，提高程序的效率。　　我们先来看一下列图1所示的VI。翻开Tool>>Profile>>ShowBufferAllocations工具查看一下这个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中的程序，数据量较大，但是并没有比拟耗时的运算操作，或数据读写操作，这样的程序，串行运算比并行效率更高。