LabVIEW的运行效率程序慢在哪里

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

2、运行效率的瓶颈通常就出现在这些部 分。所以在设计程序时，对这些部分要格外注意。a）读写外设、文件相对于计算机的中央处理器、内存读写的速度而言，计算机的外围设备的处理和传输数据的速度是非 常慢的。比如，GPIB的传输速率最高也只有1Mbps,比内存的传输速率低了两个数量级以上。在一个测试应用软件中，造成整个系统效率低下的瓶颈很可能就在于这类数据传输当中，程序的大部分时间都消耗 在等待外部数据上了。b）界面界面刷新和等待事件也是比较耗费时间的工作，这是由于人的反应速度远不如计算机引起的。比如你 可以设置屏幕上的数据指示控件中的数值以每秒一千次的速度刷新，但是这对于用户来说毫无意义，因为 人眼和大脑

3、根本处理不了如此快速的变化。还有，在显示给用户一条信息后，等待用户的后续指令也需要 等待一段时间。c）循环内的运算设计循环的时候总是要格外小心些，因为就算一段代码运行得再快，循环个几千，甚至几百万次，耗 费是时间也不得了了。所以越是执行次数多的循环，他内部代码的效率对整体影响越大。d） Global Variable全局变量不但会破坏 LabVIEW的代码风格，并且它的代码读写速度也是特别的慢。e）子 VI使用子VI是会有一定开销的，但是我们在其它文章（LabVIEW程序的内存优化）里曾经讨论过，使用子VI利大于弊。从这一点来说，子 VI使用得越多越好。不过需要注意的是，动态调用子 VI的速度

4、是非 常慢的。因为他需要先把被调用的 VI从磁盘装入到内存中， 然后才能运行。而且，装载VI的工作一定是 在界面线程（LabVIEW 的执行系统）中执行的。如果被动态调用的VI太大，就会迟滞界面刷新，影响用户的感觉。f）调试信息这一条对于已经做成可执行文件的程序是没有意义，因为 LabVIEW 在把VI转换成可执行文件的时 候，一定会去除调试信息的。但是还有相当一部分程序是以.vi文件的格式，直接在 LabVIEW 的编译环境中运行的，去除调试信息可以让这种程序降低约50%的CPU占用时间和内存。g）多线程和内存使用不当LabVIEW 是自动多线程运行的，并且自动开辟、回收内存空间。这意味着对

5、于LabVIEW 初级用户 来说，可以不去关心有关线程和内存的问题。但是对于高级用户而言，需要追求更高的效率，还是需要考 虑多线程和内存对程序的影响的。制度说明制度是以执行力为保障的。制度”之所以可以 对个人行为起到约束的作用，是以有效的执行 力为前提的，即有强制力保证其执行和实施， 否则制度的约束力将无从实现，对人们的行为 也将起不到任何的规范作用。只有通过执行的 过程制度才成为现实的制度，就像是一把标 尺，如果没有被用来划线、测量，它将无异于 普通的木条或钢板，只能是可能性的标尺，而 不是现实的标尺。制度亦并非单纯的规则条 文，规则条文是死板的，静态的，而制度是对 人们的行为发生作用的，动态的，而且是操作 灵活，时常变化的。是