Help us understand the problem. What is going on with this article?

RStudioのProfileを使ってみる

More than 3 years have passed since last update.

RStudio v1.0から正式サポートされた機能の中に、profvisを使ったパフォーマンスプロファイリングがあります。
ここでは、このprofileに関してさっくり触れてみたいと思います。

何ができるの?

解析対象のソースに対して、行単位or呼び出される関数単位でメモリの消費と処理時間を計測することができます。
行単位の結果はFlame Graphタブ、関数の呼び出し毎の結果はDataタブで見ることができます。

※ちなみに、ほぼ10msec程度で処理が終わるようなものは、プロファイラが処理を拾えないので何もできないので、ご注意を。。。

実際にプロファイリングしてみましょう

ということで、実際にやりつつ詳しく追ってみましょう。
今回はテストで次のようなスクリプトをまずは走らせてみましょう。
この例は、Rで処理が遅くなるのでやっちゃダメな典型例としておなじみの
ベクター処理が可能なものをfor分で処理したケースです。

n <- 7

# パターン1
# Cなんかでやってると普通だけど、
# Rの言語特徴的にダメダメなやり方
x <- 1:(10^n)
for(i in 1:length(x)){
 x[i] <- x[i] + 1
}

こんな感じで、ソースの行を選択してProfile Selected Linesを選択すると、プロファイリングが開始します。
004.jpeg

選択した行の処理が全て終わると次のように、プロファイリング結果表示画面が自動的に出てきます。
003.jpeg

上のパネルではFlame GraphDataという2つのタブがあります。
自動的に開かているはずのFrame Graphでは、行単位でのメモリ・処理時間の分析結果が表示されてますね。

下の部分には10ms単位でどんな処理が走っていたかが表示されます。
Dec-11-2016 00-00-02.gif
マウスオーバーすると、より詳細が見ることができます。

処理のバー部分をダブルクリックすると、その部分をズームして見ることができます。
Dec-11-2016 00-02-48.gif

今回の例の実行結果を見ると、各配列の要素に加算をしている間で
ちょくちょくガーベジコレクションが働いていてパフォーマンスが低下しているのがわかりますね。

では、さきほどの処理と同じものをRらしくベクター処理として計算するとどうなるか、試してみましょう。
流すスクリプトは次の通りで、プロファイリングのやり方は一緒です。

# パターン2
# Rでは本来こうやるべきな書き方
x <- 1:(10^n)
x <- x + 1

実行結果はこうなります。
005.jpeg

パターン1と比べると処理時間が14410msから70msへ約200倍早くなってるのがわかりますね。
また、メモリ最大消費部分も倍近く違いがあるのがわかりますね。
また、処理の途中はガーベジコレクションが一切働いていないので、なぜforを使わない方が効率の良いのかがよくわかりますね。

さて、実際の処理では同じ関数をいろんなところで複数回呼び出すというケースが考えられますね。
そういう場合はDataタブを使う方が良いはずです。
Dataタブでは、どのコールで処理に時間が食っているか、関数の呼び出し関係から見る事が出来ます。

といっても、ピンと来ないと思うので次のようなテストスクリプトを流して結果を見てみましょう。
これは、パターン1とパターン2をわざと関数化して処理しているだけです。

add_me <- function(x1, x2){
 return(x1+x2)
}

x <- 1:(10^n)
for(i in 1:length(x)){
 x[i] <- add_me(x[i], 1)
}

x <- 1:(10^n)
x <- add_me(x, 1)

この実行結果をDataタブで見てみると。。。
006.jpeg
add_me関数の呼び出しと、その中でさらに評価されている関数たちのメモリ・CPU消費具合の合計が見えます。
ここでは、処理結果を変数に入れている部分が結局のところ高価な処理になってるみたいですね。

ここで、実験的にパイプを使ったコードを評価するとどうなるか?を試してみましょう。
テストスクリプトは先程のケースで使った関数と、magrittrを使って次の通りのを試してみましょう。

x %>% add_me(1)

007.jpeg

008.jpeg

おやおや、随分と複雑になってしまいましたね。。。
パイプ演算子の中身をズルズルっと評価して表示しているため、仕方ない状況なわけですね。
とは言え、関数の呼び出しが複雑なものの、メモリ消費や処理速度は今までの中で最も優れているのはわかりますね。

こんな感じで何だか処理が重いなーという時は、Profileを立ち上げて
コードの臭い部分をささっとあぶり出して、より効率の良い分析作業に繋げていきましょう!!

ENJOY!

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away