解決策
LabVIEW はグラフィカルにプログラミングが可能な強力なツールですが、CPU の処理速度やメモリ（RAM）のサイズは有限ですので、特に大規模なプログラムの場合には、期待したパフォーマンスが得られない問題が表面化しやすくなります。
LabVIEW プログラミングにおけるパフォーマンスとメモリ使用の問題及び対策については、 LabVIEW ヘルプ » 「基本機能」 » 「パフォーマンスおよびメモリを管理する 」内の 「VI の実行速度」、「VI のメモリ使用」 及び「大きなデータセットのメモリ管理」のトピックと、関連リンク内の技術資料に詳しく書かれています。
以下では、その中でも特に問題の原因となりやすいプログラムの組み方と対策を列挙します。
-
巨大なブロックダイアグラム
プログラムに変更が加えられた VI は、保存時や実行時（実行ボタンをクリックした時）にコードがコンパイルされます。ブロックダイアグラムが大きい場合には、ごく一部のプログラムの変更であってもプログラム全体のコードがコンパイルされるため、時間がかかり、メモリを大量に消費する原因になります。弊社では個々の VI のブロックダイアグラムが画面一個分に納まる程度に、プログラムを適切にサブ VI に分割することを奨励しています。ブロックダイアグラム全体を表示する機能として、LabVIEW にはナビゲーションウィンドウ機能（表示 » ナビゲーションウィンドウ）が用意されていますが、ナビゲーションウィンドウに頼らずに開発できる状態が理想的です。巨大のブロックダイアグラムにおいてはワイヤ配線が困難になり、非効率なローカル変数に頼らざるを得なくなる問題もあります。
また、関連リンクの「フロントパネルとブロックダイアグラムの最大サイズ」で説明されているように、ブロックダイアグラムが上限サイズに近づくにつれて予期せぬ現象が起きるようになりますので、注意が必要です。
-
ローカル変数やグローバル変数
ローカル変数やグローバル変数を読み取ると、LabVIEWがデータのコピーを生成する原因となります。特にデータサイズの大きい配列や文字列のローカル変数やグローバル変数の使用は注意が必要です。 While ループや For ループにおいて反復間でデータをやりとりする際に、長いワイヤ配線を避ける目的でローカル変数を使用するのではなく、フィードバックノード又はシフトレジスタを使用します。データフローによるプログラミング言語である LabVIEW はワイヤによるデータのやりとりが最速であり、変数の使用はメモリ使用、パフォーマンスの観点から極力避けるようにします。
-
グラフやチャート
フロントパネル上の制御器や表示器、特にグラフやチャートの更新はプログラムにおいて最も負担の大きい処理の一つとなる場合があります。また、開かれているフロントパネルの制御器や表示器は表示するデータのコピーを保持するためその分のメモリを消費します。デフォルト値として膨大なデータが保存されている場合にはロードに時間を要する場合があります。
-
ループ内でのデータサイズ変更
入力データサイズと出力データサイズが異なる「配列連結追加」関数や「文字列連結」関数といったノードは、共有リソースであるメモリマネージャを呼び出してメモリを再確保するため、特に While ループや For ループ内で繰り返し呼び出すとジッタや過度なメモリ消費の原因となります。改善策としては、データサイズがループのたびに変更されないよう、配列を事前に割り当ててから「部分配列置換」関数を使用して値を置換していき、最後に置換された部分のみを取り出すというプログラミング手法があります。その際には、「部分配列置換」関数は配列サイズを変更しないため、最初に十分なサイズの配列を割り当てる必要があります。添付のサンプル VI をご参照ください。
メモ: この画像は、プロジェクトで再利用できるLabVIEWコードを含むLabVIEWスニペットです。スニペットを使用するには、画像を右クリックしてコンピュータに保存し、ファイルをLabVIEWダイアグラムにドラッグします。
-
Express VI
Express VI は対話式のダイアログボックスによりアプリケーション開発時間を短縮することができますが、大抵の場合、下位のノードでプログラムする場合に比べて処理が重く、より多くのメモリを消費します。パフォーマンスが要求されるプログラムにおいては、特にループ内での Express VI の使用は極力避けるようにします。