找到labview程序運(yùn)行速度的瓶頸

找到程序運(yùn)行速度的瓶頸、找到程序運(yùn)行速度的瓶頸想要提高程序的運(yùn)行效率，首先要找到程序運(yùn)行的瓶頸在哪里。LabVIEW程序的運(yùn)行也符合80/20定理：20%的程序代碼占用了80%的運(yùn)行時(shí)間。如果能找到這20%的代碼，加以優(yōu)化，就可以花較小的力氣，顯著提高程序的整體效率。對于已經(jīng)編寫好的程序，可以通過內(nèi)存和信息工具來查看程序中每個VI運(yùn)行的多長時(shí)間。對程序的效率進(jìn)行優(yōu)化，就要從最耗時(shí)的VI開始下手。內(nèi)存和信息工具可以從LabVIEW的菜單項(xiàng)Tools->Profile->PerformanceandMemory中啟動。圖1是這個工具的界面。進(jìn)占用了大量CPU時(shí)間內(nèi)存和信息（Profileperformancei- 0信息工具中會列出一個程序中的全部子VI。在運(yùn)行這這個工具就開始為所有的子VI就顯示出每個子VI束，點(diǎn)擊工具上的SnapshotJj-*a￡rJvandMemoryi進(jìn)占用了大量CPU時(shí)間內(nèi)存和信息（Profileperformancei- 0信息工具中會列出一個程序中的全部子VI。在運(yùn)行這這個工具就開始為所有的子VI就顯示出每個子VI束，點(diǎn)擊工具上的SnapshotJj-*a￡rJvandMemoryi石 1的Start按鈕CPU時(shí)間。按照VITime排序，排在最前面的■ Ji I! ■是需要重點(diǎn)優(yōu)化的對象衍有可能是因?yàn)樗鼉?nèi)部的運(yùn)4?1在內(nèi)存和先按下工具的程序運(yùn)行中占用了多少程序的瓶頸，一個子V工具個程序之前，￡剛剛的運(yùn)行［個VI就是這時(shí)你需要打開它，對它的算法進(jìn)行優(yōu)化。但更有可能的是因?yàn)檫@個VI被程序執(zhí)行的次數(shù)太多。這時(shí)，你就要考慮的程序結(jié)構(gòu)，是否可以減少這個VI的運(yùn)行次數(shù)，比如把它從某些不必要的循環(huán)中挪出去，或者拆分這個VI的代碼，把沒有必要循環(huán)執(zhí)行的部分分離出去，挪到循環(huán)體外面。并不是所有的運(yùn)行效率問題都可以在內(nèi)存和信息工具中體現(xiàn)出來。VITime列出的只是子VI的CPU占用時(shí)間，如果你的程序里存在大量無用的延時(shí)，或者程序一直被某些慢速工作，如讀寫外部儀器，通過網(wǎng)絡(luò)傳輸數(shù)據(jù)等，所阻塞。這樣的程序效率也是很低de，但在內(nèi)存和信息工具上卻體現(xiàn)不出來。有些非常耗用CPU的操作也無法體現(xiàn)在內(nèi)存和信息工具上。比如我將會在《LabVIEW的線程》第四章提到一個使用OpenGL的例子，由于程序線程設(shè)計(jì)不當(dāng)，CPU被大量消耗在線程切換上。從系統(tǒng)資源管理器看，CPU被LabVIEW占滿，在內(nèi)存和信息工具卻看不到任何一個VI占用了如此多的CPU時(shí)間。在多核CPU的計(jì)算機(jī)上，由于可以多個線程同時(shí)執(zhí)行，某些子VI雖然占用的大量的CPU時(shí)間，如果程序線程設(shè)置合理，是可以讓這些VI不影響到程序的整體效率的。二、程序慢在哪里？使用內(nèi)存和信息工具是不能發(fā)現(xiàn)所有程序效率問題的。并且一旦程序的主體實(shí)現(xiàn)以完成，在對其進(jìn)行修改，成本還是比較高的，尤其是涉及到結(jié)構(gòu)性的改動時(shí)：以前做過的測試需要重新做，構(gòu)建在這個模塊之上的代碼需要作相應(yīng)更新。如果時(shí)間緊迫，考慮到這這種改動所帶來的風(fēng)險(xiǎn)，很可能在程序完成后就無法在對其性能進(jìn)行優(yōu)化了。所以最有效的編寫高效率程序的方法，不是在程序完成后，再回頭查找程序瓶頸。而是在設(shè)計(jì)程序結(jié)構(gòu)的時(shí)候，就把會影響程序效率的因素考慮進(jìn)去。直接設(shè)計(jì)出高效率的程序。下面討論一些常見的運(yùn)行比較慢的程序部分。一個程序運(yùn)行效率的瓶頸通常就出現(xiàn)在這些部分。所以在設(shè)計(jì)程序時(shí)，對這些部分要格外注意。a)讀寫外設(shè)、文件相對于計(jì)算機(jī)的中央處理器、內(nèi)存讀寫的速度，計(jì)算機(jī)的外圍設(shè)備的處理和傳輸數(shù)據(jù)的速度是非常慢的。比如，GPIB的傳輸速率最高也只有1Mbps，比內(nèi)存的傳輸速率低了兩個數(shù)量級以上。在一個測試應(yīng)用軟件中，造成整個系統(tǒng)效率低下的瓶頸很可能就在于這類數(shù)據(jù)傳輸當(dāng)中，程序的大部分時(shí)間都消耗在等待外部數(shù)據(jù)上了。b)界面界面刷新和等待事件也是比較耗費(fèi)時(shí)間的工作。這是由于人的反應(yīng)速度遠(yuǎn)不如計(jì)算機(jī)引起的。你如你可以設(shè)置屏幕上的數(shù)據(jù)指示控件的中數(shù)值以每秒一千次的速度刷新，但是這對于用戶來說毫無意義，因?yàn)槿搜酆痛竽X根本處理不了這樣快的變化。同樣，在顯示給用戶一條信息后，等待用戶的后續(xù)指令也需要一段時(shí)間。循環(huán)內(nèi)的運(yùn)算設(shè)計(jì)循環(huán)的時(shí)候總是要格外小心些，因?yàn)榫退阋欢未a運(yùn)行的再快，循環(huán)個幾千，甚至幾百萬次，耗費(fèi)是時(shí)間也不得了了。所以越是執(zhí)行次數(shù)多的循環(huán)，他內(nèi)部代碼的效率對整體影響越大。GlobalVariable全局變量不但會破壞LabVIEW的代碼風(fēng)格，并且它的代碼讀寫速度也是特別的慢。e)子VI使用子VI是會有一定開銷的，但是我們在其它文章里曾經(jīng)討論過，使用子VI利大于弊。子VI使用的越多越好。不過需要注意的是，動態(tài)調(diào)用子VI的速度是非常慢的。因?yàn)樗枰劝驯徽{(diào)用的VI從磁盤裝入到內(nèi)存中，然后才能運(yùn)行。而且，裝載VI的工作一定會在界面線程執(zhí)行。如果被動態(tài)調(diào)用的VI太大，還會遲滯界面刷新，影響用戶的感覺。f)調(diào)試信息這一條對于對于已經(jīng)做成可執(zhí)行文件的程序沒有意義，因?yàn)長abVIEW在把VI做成可執(zhí)行文件的時(shí)候，一定會去除調(diào)試信息的。但是還有相當(dāng)一部分程序是直接在LabVIEW的編譯環(huán)境下運(yùn)行的，去掉調(diào)試信息可以讓程序降低約50%的CPU占用時(shí)間。g)多線程和內(nèi)存使用不當(dāng)LabVIEW是自動多線程運(yùn)行，