LabVIEW程序慢在哪里

marere_re

LabVIEW程序慢在哪里？
使用内存和信息工具是不能发现所有程序效率问题的。并且一旦程序的主体实现以完成，在对其进行修改，成本还是比较高的，尤其是涉及到结构性的改动时：以前做过的测试需要重新做，构建在这个模块之上的代码需要作相应更新。如果时间紧迫，考虑到这这种改动所带来的风险，很可能在程序完成后就无法在对其性能进行优化了。
    所以最有效的编写高效率程序的方法，不是在程序完成后，再回头查找程序瓶颈。而是在设计程序结构的时候，就把会影响程序效率的因素考虑进去。直接设计出高效率的程序。

    下面讨论一些常见的运行比较慢的程序部分。一个程序运行效率的瓶颈通常就出现在这些部分。所以在设计程序时，对这些部分要格外注意。

    a) 读写外设、文件
    相对于计算机的中央处理器、内存读写的速度，计算机的外围设备的处理和传输数据的速度是非常慢的。比如，GPIB 的传输速率最高也只有 1Mbps，比内存的传输速率低了两个数量级以上。在一个测试应用软件中，造成整个系统效率低下的瓶颈很可能就在于这类数据传输当中，程序的大部分时间都消耗在等待外部数据上了。

    b) 界面
    界面刷新和等待事件也是比较耗费时间的工作。这是由于人的反应速度远不如计算机引起的。你如你可以设置屏幕上的数据指示控件的中数值以每秒一千次的速度刷新，但是这对于用户来说毫无意义，因为人眼和大脑根本处理不了这样快的变化。同样，在显示给用户一条信息后，等待用户的后续指令也需要一段时间。

    c) 循环内的运算
    设计循环的时候总是要格外小心些，因为就算一段代码运行的再快，循环个几千，甚至几百万次，耗费是时间也不得了了。所以越是执行次数多的循环，他内部代码的效率对整体影响越大。

    d) Global Variable
    全局变量不但会破坏LabVIEW的代码风格，并且它的代码读写速度也是特别的慢。

    e) 子VI
    使用子VI是会有一定开销的，但是我们在其它文章里曾经讨论过，使用子VI利大于弊。子VI使用的越多越好。不过需要注意的是，动态调用子VI的速度是非常慢的。因为他需要先把被调用的VI从磁盘装入到内存中，然后才能运行。而且，装载 VI 的工作一定会在界面线程执行。如果被动态调用的 VI 太大，还会迟滞界面刷新，影响用户的感觉。

    f) 调试信息
    这一条对于对于已经做成可执行文件的程序没有意义，因为 LabVIEW 在把 VI 做成可执行文件的时候，一定会去除调试信息的。但是还有相当一部分程序是直接在 LabVIEW 的编译环境下运行的，去掉调试信息可以让程序降低约 50% 的 CPU 占用时间。

    g) 多线程和内存使用不当
    LabVIEW 是自动多线程运行，和自动开辟回收内存空间的，这意味着对于 LabVIEW 初级用户可以毫不关心有关线程和内存的问题。但是对于高级用户，需要追求更高的效率，就需要考虑多线程和内存对程序的影响了。