前幾天，聽到了乙個客戶的抱怨：他編寫了乙個labview程式，每次開啟主程式就要花費幾分鐘的時間，這有點令他忍無可忍。我沒有見過他的源程式，不過據幫他檢查過程式的同事講，他的問題很可能是使用了大量的lvclass造成的。在他的專案中，包含有上百個類（lvclass）。我以前也聽說過lvclass在效率上可能會有些問題，聽到了這個訊息後，我自己做了乙個實驗。
labview scripting中有乙個屬性節點可以用來檢視記憶體中所有的vi，我就利用這個vi來檢視乙個程式到底在裝入些什麼，令它啟動如此之慢。
假設不存在子vi，如果開啟某個不在lvclass中的vi（即便這個vi是屬於某個lvlib的），只有這個vi會被裝入記憶體。但是，開啟某乙個lvclass中的vi，我發現不但這個vi會被裝入記憶體，它所在的類中的所有其它的vi也都被調入記憶體。如果這個類還有父類和祖先類，那麼所有父類、祖先類中的vi統統都會被調入記憶體。
總結一下就是這樣：當乙個vi被裝入記憶體
它的所有子vi都會被裝入記憶體；
它所在的類中的所有的vi都會被裝入記憶體；
它所在的類的父類中的所有的vi都會被裝入記憶體。
以上3條可以是遞迴發生的，比如乙個主vi a被裝入記憶體，它的子vi b也會被裝入記憶體，和b同屬乙個類的vi c也要被裝入記憶體，c中有個子vi d，d屬於類e，e有個父類f，f中有個方法vi g。儘管g的功能和程式a八桿子都打不著了，但也會被裝進來。這大概就是那個使用者遇到的問題，表面上他的程式不算太大，但是程式開始啟動時，卻需要把多於程式本身數倍的不相關的vi都裝入記憶體，這一過程會每次都浪費他幾分鐘的時間。
鑑於lvclass的這一特性，設計使用它的時候一定要格外小心，否則很可能會造成程式效率的低下。我想到了幾點需要注意的地方：
如果僅需要對一些vi進行封裝，那麼應當使用lvlib，而不是lvclass。兩者封裝的主要區別是，lvclass可以封裝物件的屬性（也就是模組用到的資料）。
類中的vi必須是高內聚的，類中的方法共同完成某一基本功能，不可再分割。應用程式一旦用到這個類中的某個vi，就意味著程式將會使用到類中幾乎全部的vi；而不是乙個應用程式可能只使用這個類中的某幾個vi。
繼承關係應當盡量簡單。沒有必要的時候盡量不使用繼承。labview不支援介面，不應建立乙個純虛類，然後當作介面來用。
盡量不要巢狀呼叫。比如在乙個類的vi中又去呼叫另乙個類中的vi。
打算使用多型這個特性時要注意，多型使得應用程式在執行時，根據物件的型別選擇對應的處理方法。但有些選擇應當是程式編譯時就做出的，它們不適合套用在多型特性上。
舉一些例子：
乙個effective java中的效率問題
package com.liuc public class autopackage long end system.currenttimemillis system.out.println end start 1000 執行時間19s 和下面這個程式 package com.liuc public ...
乙個Linq效率（智慧型程度）的測試
今天做了一次linq的測試，如下 new dataclasses1datacontext in db.blogs 這是個較為複雜的查詢，包含兩個跨表聯合，更重要的是，最終需要的是count，而並不是整個blog列表，考驗的是linq的智慧型程度。用sql profile分析，得到對應的sql是 se...
如何摧毀乙個程式設計師的效率？
如何摧毀乙個程式設計師的效率？如何摧毀乙個程式設計師的效率 有時我什麼事都幹不了。當然，我走進辦公室，到處閒逛，十秒鐘就檢查一次電郵，看網頁，甚至幹些不用腦子的事，比如支付美國運通的賬單。但就是不會回到寫 的流程上來。這樣的低效症一發作一般都要持續一兩天。但在我的職業生涯裡，作為程式設計師，曾經好幾...