將元素置入 LabVIEW 陣列首部的效率比較

對於一個 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 次,並取得平均的執行時間。

L8192 three vs.png

三者的結果如下圖。前兩者的做法理論上等效,實際上 Build Array 的做法快了 Insert Into Array 一點點(12.3 μs 對上 12.7 μs),多測試幾次結果仍一樣。至於以 Reverse 1D Array 為基礎的「先反轉,置尾後再反轉」的做法似乎沒有效率上的優勢(37.7 μs)。

L8192 result three vs.png

為了釐清問題,先將陣列的「置首」、「置尾」與「反轉」的執行速度進行比較。程式與結果如下。測試對象一樣是長度是 8192 的 Double 陣列。

L8192 vs begin end and re.png

L8192 result vs begin end and re.png

從結果可以發現,「置尾」的速度確實快上「置首」許多(154 ns 對上 13.6 μs)。而即使是陣列的「反轉」也只需要平均 15.8 ns。

從上述記錄來看,各別把「反轉」、「置尾」與「反轉」三個動作加總,執行的平均速度也不到 200 ns,相較於直接「置首」的 13.6 µs 仍有極大優勢。但為何串在一起執行優勢就消失了?可能的原因是 LabVIEW 的資料流的特性,造成了「先反轉,置尾後再反轉」的過程中出現了額外記憶體的複製。

下面是將測試陣列的長度縮短為 128 的結果。「先反轉,置尾後再反轉」仍然是吊車尾(2.81 μs),不過在小陣列的情況下,三者的效率已經在同一個數量級了。

L128 result.png

所以,在 LabVIEW 的開發環境下,不用想太多,按直覺來操作陣列即可。小陣列、少量寫入的陣列操作的效能甚至相差無幾。至於將程式 build 成執行檔後的效能差異,那就是另一個故事了(待續)。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s