Rスピードが恋しいですか? 隠れた埋蔵量を探しています

時には、通訳者であるRが「速い」ビジネスのタスクを分析するには遅すぎるという信念に出くわす必要があります。 ほとんどの場合、このような要約は、次のような深刻なソフトウェアの開発経験がないアナリストからのものです。 限られたハードウェアリソースに非常に厳しい高性能または組み込みシステム。 これは完全に普通のことで、誰も世界のすべてを知ることはできません。 ただし、95%のケースでは、Rがそれとは無関係であることが判明しています;問題は、メモリ管理と計算プロセスが効果的でないことです。







したがって、このメモでは、5つの重要なポイント(6と10に言及できますが、5つあります)に触れます。この作業は非常に頻繁に低速コードの変換に役立ちます。 原則自体は長い間知られていたため、記録はかなり抽象的であり、Rへの着陸である。 既存のコードの可能な最適化に関する研究を開始するための「チートシート」。







  1. 計算されたデータはすべてRAMにある必要があります。







  2. ループ変数に関するすべての不変量は、ループ外で計算する必要があります。







  3. コピーオブジェクトを効率的に使用します。







  4. オブジェクトの構造に従い、ゴミをきれいにします。







  5. 賢明に最適化します。


次は手順です。







RAMのすべて



データを「単純に」処理しないでください。 タスクを分析し、作業中のデータ量を計算し、利用可能なRAMに見合った自律的なデータブロックにデータを分割する方法を確認します。 これらのブロックを順番にカウントすることも、可能であれば、各独立ブロックで作業を並列化することもできます(「Map-Reduce」)。 ディスクへのスワップ-パフォーマンスを数桁圧縮します。







「かっこから外す」



分配性の単純な代数的性質は、これまで以上にサイクリックコンピューティングに関連しています。 関数アプローチで明示的または非表示になっている計算は、ループインデックスとはまったく関係ありませんが、ループから除外する必要があります。 何度も使用される長時間計算された値は、プログラムの本体の外部で取得し、表形式の値の形式で表示することが非常に望ましいです。 数マイクロ秒の追加の長いサイクルは、数時間、数日を作ることができます。







コピーを追跡する



高レベル言語では、多くの追加サービスとメタ情報を含むかなり複雑な構造を各オブジェクト/変数の背後に隠すことができます。 そして、次のようなオブジェクトに対して操作を実行するための簡単な手順:







t <- f(t, n)
      
      





動的なメモリ割り当てにつながり、1ダースバイトから遠く離れてコピーする可能性があります。 ループに配置されると、このようなプロシージャは、任意のプロセッサの任意の周波数を消費して、さらに多くを要求する可能性があります。







ゴミを捨てる



RAMを保護します。 オブジェクトを使用し、もう必要ないのですか? 手動で削除します。ガベージコレクターを待たないでください。 あなたは待つことができません。







回帰を考慮し、値のテーブルのみが必要ですか? lm



オブジェクトの重量と、余計なものを知っていますか?

例として、ブログエントリ: 「Rメモリフットプリントを7000x削減」







関数を効果的に使用しますか? それらがどのように配置されているか知っていますか? 別の興味深い例を次に示します。







 t <- raw.df$timestamp object.size(t) #    130  m <- lapply(t, function(x){round(x, units="hours")}) #   130   35  m <- lapply(t, function(x){round_date(x, unit = "hour")}) #   8 !!! m <- round_date(t, unit = "hour") # 130 ,     
      
      





読み取りだけでなく、このオブジェクトを引き続き使用する場合、130kbまたは35Mbを処理する方が速いでしょうか? 私の意見では、答えは非常に明白です。







コードの最適化



コードの実行が遅い場合は、実行プロファイルを参照してください。 ボトルネックを見つけて最適化します。 重要でないノードの最適化に時間を無駄にしないでください。







そして、偉大な科学者の声明を忘れないでください。「本当の問題は、プログラマーが間違った場所で間違った時間に効率を心配しすぎているということです。時期尚早な最適化はすべての悪の根源です(少なくともその大部分)プログラミング。」 -ドナルド・クヌース、講演、コンピュータープログラミングとしてのアート、Communications of the ACM(Vol。17、Issue 12、1974年12月、671ページ)に掲載







デバッグとプロファイリングに関する推奨事項の役立つリンク。









おわりに



練習は必然的に、これらの簡単な推奨事項は、高価なハードウェアのアップグレード、複雑なオーケストレーションでの並列コンピューティングへの切り替え、またはいくつかのコンピューティング機能をC \ C ++モジュールに移動することなく、小さな変更によってコードを何倍も高速化するのに非常に頻繁に役立つことを示しています。







前の投稿: 「Rを使用してステートメントを処理する」誰が責任を負うのか?もちろん、IT! ""

次の投稿: 「ビジネスサービスへのハーネスR」1-2-3 ""








All Articles