|
在LabVIEW 2009和LabVIEW 2010中,给LabVIEW的编译器增加了许多优化措施以加快VI和可执行程序
运行时间和性能。虽然这些优化可以显着提高程序的执行时间,但是代价是增加了编辑时间的开销。
有了这些额外的优化,编译时间变得更长,编译时使用到的内存会更高。在大多数情况下,这些变化
可以忽略不计,用户是注意不到其中的差别。然而,美国国家仪器公司注意到了,一些非常大的VI
在这些领域表现有所退化,本来可用的变得相当难用。要不是应用程序在编译时内存益出就是VI的保存
时间(由于编译)变得很长。
我们所收到的大多数例子包含了深层嵌套的结构,有许多自己的图表(例如,包含了一个有100个状态
的状态机,每一状态还包含了序列堆栈)。虽然这些图可能在屏幕上并不大,但庞大的节点和子图
将对编译器的性能产生重大影响。
****更新 LabVIEW 2010 SP1****
编译器的优化是效益和性能的折衷,优化也根据应用程序的不同而不同的。 LabVIEW 2010 SP1现在允许你根据应用程序的需要来改变优化的设置。默认情况下,对于大部分VI所有编译器的优化选项是使能的,然而现在一旦程序框图的大小会使编译时间难以预测,一些选项会自动被禁止。关于如何调整的阀值的说明文档可以在知识库里找到。
非常感谢那些贡献能够使我们的产品变慢的源代码的使用者。如果你在更新到LabVIEW 2010 SP1后还遇到了编译和保存时间问题,或者性能还不如之前版本的LabVIEW时,希望您能够和
美国国家仪器的技术支持联系。
原始的解决办法
LabVIEW在加载,运行或保存(如有必要)的过程中将自动编译你的VI。在一般情况下,任何非装饰上的改变都会设置一个标志,表明这个VI需要重新编译。当此标志被设置了,在运行或保存时VI会自动编译。
理想的解决办法是,通过在您巨大的程序框图中创建子VI的办法来减小您VI的大小。当您在编译VI时子VI是不会重新编译的,这样提高了保存时间的性能。此外,创建更多的模块化代码也将有助于让您的代码在开发过程中更有组织性。
保存时间太长的解决方法
在编程时会有意地破坏你自己的VI。 在保存操作过程中LabVIEW不会编译断开了的VI;它只会保存源代码,使得保存操作完成速度明显加快。一个简单的方法来完成这个,就是在程序框图中删除或添加一些不连线的节点。当你准备好运行你的VI时,你可以删除或添加那些节点,在下次您运行或保存时VI将会被编译。
内存用光的解决办法
让你的操作系统使用更多的内存。你可以扩展32位的Windows机器的虚拟内存以使用户的应用程序(这里是指LabVIEW)可以使用3GB的内存,而不仅仅只是2GB。64位的操作系统可以允许32位的应用程序使用4GB的虚拟内存。
毫无疑问的是LabVIEW的研发部门的当务之急是增强LabVIEW的编译器的性能。我们正在为将来发行的LabVIEW努力工作,以减少编译器的编译时间和编译时所使用的内存。在这一过程中我们希望您向我们发送任何你有的可以测试这些性能的代码。你们的参与将有助于我们确保我们的应用程序有最广的适用范围。如果你有技术支持合同或者张贴你的代码于本论坛,您还可以记录一个向我们的应用工程师请求的帮助。
如果您还有其它的问题或者有问题需要帮助请联系美国国家仪器技术支持。
|