對於一個 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 成執行檔後的效能差異，那就是另一個故事了（待續）。
科科仔 