labview局部变量,属性节点和数据流的性能比较

我们知道,在一个独立的VI中,可以通过局部变量,属性节点和数据流的方式来更改一个指示器的值,其中局部变量和属性节点即可以用于控制器又可以用于指示器.而数据流是不能直接在两个指示器中进行数据传递的.

下面分别用三种传递数据的方法来分析一下它们的区别和运行效率.

在第三个框图中,最初我用的是和上两个框图同样的运行次数,等的10几分钟都无法自行完毕,没办法运行次数降至原来的1/1000,那实际运行时间应该是4091MS*1000,居然需要一个多小时.
在三个框图中，始终保持控制器的值不便，避免了控件更新最速度造成的影响．
可以看出，ＬＶ倡导的数据流的速度是最快的，局部变量略低一些，而属性节点对速度的影响已经是不能不考虑的事情了．
属性节点对程序效率的影响为何如此惊人那，基于ＷＩＮＤＯＷＳ操作系统的考虑，任何涉及到界面操作操作的都是基于ＷＩＮＤＯＷＳ消息队列的，属性节点的操作应该是通过控件类，是属于界面接口线程的,因此对它的操作耗费大量的时间是可以理解的.
那么,读属性节点和写属性节点有无区别那.
我们知道,在一个独立的VI中,可以通过局部变量,属性节点和数据流的方式来更改一个指示器的值,其中局部变量和属性节点即可以用于控制器又可以用于指示器.而数据流是不能直接在两个指示器中进行数据传递的.

下面分别用三种传递数据的方法来分析一下它们的区别和运行效率.

在第三个框图中,最初我用的是和上两个框图同样的运行次数,等的10几分钟都无法自行完毕,没办法运行次数降至原来的1/1000,那实际运行时间应该是4091MS*1000,居然需要一个多小时.
在三个框图中，始终保持控制器的值不便，避免了控件更新最速度造成的影响．
可以看出，ＬＶ倡导的数据流的速度是最快的，局部变量略低一些，而属性节点对速度的影响已经是不能不考虑的事情了．
属性节点对程序效率的影响为何如此惊人那，基于ＷＩＮＤＯＷＳ操作系统的考虑，任何涉及到界面操作操作的都是基于ＷＩＮＤＯＷＳ消息队列的，属性节点的操作应该是通过控件类，是属于界面接口线程的

可见,写属性节点耗费的时间是读属性节点的100多倍.
通过以上的比较,如果不是必要的话,尽量不要通过属性节点来传递数据,对于一个不显示的子VI,更是如此,任何涉及到属性节点的操作都会导致前面板载入内存,不但增加了内存的使用量,也同时引起的速度的急剧下降.
所以,在编程中一下几点是需要注意的:
1.在不需要显示的子VI中一定不要使用属性节点,需要数据传递,如果数据流无法实现,采用局部变量是比较好的选择.
2.对于需要显示的主界面,不要在循环中重复调用属性节点,可采用事件结构或者状态机方式,或者用上升下降沿来判断,保证一次性更改,一定要避免重复调用.
3.局部变量虽然用增加内存复制的问题,但是对不涉及很大的比如数组结构,可以不避考虑,至于数据竞争的问题,可以在编程中仔细考虑避免,在很多书籍中都提到了要尽量避免使用局部变量,通常给的例子都是如何用局部变量来结束两个并行循环,如果只需要实现这样的功能,LV根本就必要提供局部变量这种方便的编程方式了.

分享。。

请教小编：局部变量容易数据丢失，属性节点影响运行速度。倘若在一个比较大的程序结构中（也包含很多子程序），数据量较大，对数据的处理工作较多，这样的情况应该怎么处理比较妥当呢?求解！

分析得太好了，受教了

很好

谢谢，受用

学习了！

厉害

在一些大的程序中局部变量的使用不可避免，只要大家认真增加局部变量描述就可以放心使用，如果程序中局部变量过多，建议使用簇。

谢谢分享，学习学习

受教了，小编威武~

这样的课可以多讲讲，

挺有用的，学习下，谢谢！