對於一個 LabVIEW 陣列,將元素插入陣列的首部或尾部有極大的速度差異,後者的效率會高上 100 倍以上,因此延伸出幾種對於「將元素置入陣列首部」的寫法。以下用 Insert Into Array、Build Array 與 Reverse 1D Array 三個內建的 LabVIEW 函式來實作並比較處理速度。其中第三種方式是先將陣列反轉,將新元素寫到陣列的尾巴後再反轉回來。主要是因為是陣列反轉只轉指標,再配合陣列置尾兩個雙重的速度優勢。下面的測試是在 LabVIEW 2016 的開發環境下。
測試的程式如下。測試對象為一個長度是 8192 的 Double 陣列。由上至下分別採用 Insert Into Array、Build Array 與 Reverse 1D Array 三種方式將新元素(-1 值)置入陣列的首部 1000 次,並取得平均的執行時間。
三者的結果如下圖。前兩者的做法理論上等效,實際上 Build Array 的做法快了 Insert Into Array 一點點(12.3 μs 對上 12.7 μs),多測試幾次結果仍一樣。至於以 Reverse 1D Array 為基礎的「先反轉,置尾後再反轉」的做法似乎沒有效率上的優勢(37.7 μs)。
為了釐清問題,先將陣列的「置首」、「置尾」與「反轉」的執行速度進行比較。程式與結果如下。測試對象一樣是長度是 8192 的 Double 陣列。
從結果可以發現,「置尾」的速度確實快上「置首」許多(154 ns 對上 13.6 μs)。而即使是陣列的「反轉」也只需要平均 15.8 ns。
從上述記錄來看,各別把「反轉」、「置尾」與「反轉」三個動作加總,執行的平均速度也不到 200 ns,相較於直接「置首」的 13.6 µs 仍有極大優勢。但為何串在一起執行優勢就消失了?可能的原因是 LabVIEW 的資料流的特性,造成了「先反轉,置尾後再反轉」的過程中出現了額外記憶體的複製。
下面是將測試陣列的長度縮短為 128 的結果。「先反轉,置尾後再反轉」仍然是吊車尾(2.81 μs),不過在小陣列的情況下,三者的效率已經在同一個數量級了。
所以,在 LabVIEW 的開發環境下,不用想太多,按直覺來操作陣列即可。小陣列、少量寫入的陣列操作的效能甚至相差無幾。至於將程式 build 成執行檔後的效能差異,那就是另一個故事了(待續)。
發表迴響