Log

• 2020-04-12: 23, 24.6

  과학원에서 기상자료 QC하는 R 코드를 짰는데, 꽤 애먹었다.

  컴퓨터 메모리는 8GB.

  인풋으로 사용하는 csv 파일이 최대 2GB 정도로 크긴 했지만 메모리에는 문제가 없어 보였다.

  하지만 분명 언뜻 보기에 8GB가 넘지 않을 것 같은데도 메모리 용량 부족으로 에러가 자꾸 났다.

  읽어들인 파일을 수동으로 쪼갠 후 열심히 QC를 진행했지만… 결국 친구가 말해준 기한을 넘겨버렸다.

  내 추측에… 함수가 작동하는 과정에서 내부적으로 변수를 복사하기 때문에 메모리 사용량이 내 예상을 넘는 것 같다.

  앞으론 csv 용량을 조금 줄여서 해결할 수 있을 듯하지만,

  그래도 이번 기회에 코드 성능, 메모리 관리에 관한 내용을 알아두면 좋을 것 같아서 Hadley Godkham의 책을 들여다봤다.

  내가 원하는 내용은 23장에 있었고, 코드 성능(=run time) 및 메모리 관리 관련 내용이 담겨 있다.

5. Techniques

23. Measuring performances

23.2 Profiling

23.2.1. Visualising profiles

Profiling은 코드 한줄한줄의 runtime을 분석하는 것을 말한다.
R에서는

1. RStudio의 profile 메뉴를 이용하거나,
2. utils::Rprof(), profvis::profvis() 등의 함수를 사용할 수 있다.

profvis가 보기 편하므로 이것만 정리해야지.

먼저 프로파일할 샘플 함수를 작성하고,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

library(profvis)

f <- function() {
  pause(0.1)
  g()
  h()
}
g <- function() {
  pause(0.1)
  h()
}
h <- function() {
  pause(0.1)
}

프로파일 진행.
코드는 간단하다.

1

profvis(f())

Flame Graph 탭의 아래 패널에서는 스택 형태로 각 코드와 실행 시간을 보여준다. 간단한 코드의 프로파일 결과를 눈으로 확인하기 좋다.
코드가 복잡할 때는 Data탭에서 확인하는 게 편하다(고 한다). 탐색기 구조로 볼 수 있다.

23.2.2. Memory profiling

running time뿐만 아니라 memory 사용 내역도 프로파일로 분석할 수 있다.
프로파일 결과에 <GC> (i.e. garbage collector)라는 걸 볼 수 있는데, 더 사용되지 않는 객체를 없애는 역할을 한다. 어떻게 작동되는지 살펴보자.

샘플 garbage 객체를 만들고 이를 프로파일링하면…

1
2
3
4
5
6

profvis::profvis({
  x <- integer()
for (i in 1:1e4) {
  x <- c(x, i)
}
})

위 패널에서 메모리 부분에 막대가 생긴 걸 볼 수 있다.
오른쪽으로 뻗은 건 사용 된 메모리,
왼쪽으로 뻗은 건 <GC>가 제거한 불필요한 메모리 사용량.

찾았다.

본문에서

Here the problem arises because of copy-on-modify (Section 2.3): each iteration of the loop creates another copy of x. You’ll learn strategies to resolve this type of problem in Section 24.6.

라고 언급하는데,
저기 copy-on-modify, creastes another copy of x 부분이 내가 추측한 부분인 듯하다.
자세한 원인은 Section 2.3을, 해결법은 Section 24.6을 참고하란다.

23.2.4. Exercises

1. Profile the following function with torture = TRUE. What is surprising? Read the source code of rm() to figure out what’s going on.

1
2
3
4
5
6
7

profvis::profvis({
  f <- function(n = 1e5) {
    x <- rep(1, n)
    rm(x)
  }
},
torture = TRUE)

에러가 발생한다(‘integer'은 ‘coerceToInteger'에서 구현되지 않은 유형입니다). 솔루션을 보니 아직 해결이 안 된 듯.

23.3. Microbenchmarking

Microbenchmark는 profile을 아주 작은 코드 단위(i.e. 함수 하나)에서 수행하는 것이다.
예를 들어 csv 파일을 읽는 함수 read.csv, readr::read_csv(), data.table::fread()이 csv 파일 하나 읽는 데 걸리는 시간을 비교하는 것이 있겠다.
bench 라이브러리를 사용한다.

1
2
3
4
5

x <- runif(100)
(lb <- bench::mark(
  sqrt(x),
  x ^ 0.5
))

## # A tibble: 2 x 6
##   expression      min   median `itr/sec` mem_alloc `gc/sec`
##   <bch:expr> <bch:tm> <bch:tm>     <dbl> <bch:byt>    <dbl>
## 1 sqrt(x)       900ns    1.1us   465768.      848B        0
## 2 x^0.5         5.8us    6.1us   114983.      848B        0

결과는 tibble 형태로 저장된다.
각 row에는 비교하려는 expression이 저장된다.
여기서는 x의 루트를 계산하는 데 sqrt() 함수를 사용하는 방법과(1행) ^ 연산자를 사용하는 방법(2행)을 비교했다.
sqrt() 함수가 양 6배 빠른 것으로 나타났다.

그림으로 나타내면…

1

plot(lb)

## Loading required namespace: tidyr

이렇게 right-skewed 형태의 그림이 나타난다(그래서 평균보다는 최솟값을 비교하자).

23.3.3. Exercises

2. Here are two other ways to compute the square root of a vector. Which do you think will be fastest? Which will be slowest? Use microbenchmarking to test your answers.

1
2

x ^ (1 / 2)
exp(log(x) / 2)

루트 계산하는 두 방법을 비교해보란다. 딱 봐도 log 씌웠다가 exp()로 되돌리는 게 느려보인다.
bench::mark()를 사용해서 sqrt()도 같이 비교해보자.

1
2
3
4
5
6
7

x <- runif(100)
(lb <- bench::mark(
  sqrt(x),
  x ^ (1 / 2),
  exp(log(x) / 2)
)
)

## # A tibble: 3 x 6
##   expression         min   median `itr/sec` mem_alloc `gc/sec`
##   <bch:expr>    <bch:tm> <bch:tm>     <dbl> <bch:byt>    <dbl>
## 1 sqrt(x)            1us    1.1us   759671.      848B        0
## 2 x^(1/2)          6.1us    6.4us   141474.      848B        0
## 3 exp(log(x)/2)   13.6us   13.9us    59601.      848B        0

생각대로 나왔다. 누가 루트 구할 때 굳이 log-exp를 사용할까…
mem_alloc 열에서 사용한 메모리 양은 모두 같은 것을 확인할 수 있다.
아무튼 이런 식으로 같은 기능을 수행하는 여러 방법을 비교해볼 수 있다.

결론

profvis() 결과를 보고
어느 부분에서 시간을 많이 잡아먹고,
어느 부분에서 내 코드에 쓰레기가 많이 생기는지 파악할 수 있겠다.

profvis::profvis()가 스크립트 전체에 수행하는 프로파일이라면,
bench::mark()는 한 과정과정에 대해 실행시간&메모리 사용량을 비교해볼 수 있다.

혹시 코드 성능을 고민해야 할 때 사용해보자.

24. Improving performance

24.6 Avoiding copies

어떨 때 copy가 일어나는지 알려줄 뿐, 해결책은 알려주지 않는다.
copy 일어나는 경우 자체를 피하라는 뜻인 듯.

c(), append(), cbind, rbind(), paste(), x[i] <- y 등을 사용하면
새로 만들 object를 위한 메모리를 할당하게 된다.
c언어에서 두 변수 값을 바꾸고 싶을 때, temp 등의 새로운 변수를 이용하는 것과 비슷한 것 같다.

x <- 1
y <- 2
temp <- x
x <- y
y <- x
rm(temp)

아래 예시를 통해 copy가 얼마나 코드를 느리게 하는지 보여준다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

random_string <- function() {
  paste(sample(letters, 50, replace = TRUE), collapse = "")
}
strings10 <- replicate(10, random_string())
strings100 <- replicate(100, random_string())

collapse <- function(xs) {
  out <- ""
  for (x in xs) {
    out <- paste0(out, x)
  }
  out
}

bench::mark(
  loop10  = collapse(strings10),
  loop100 = collapse(strings100),
  vec10   = paste(strings10, collapse = ""),
  vec100  = paste(strings100, collapse = ""),
  check = FALSE
)[c("expression", "min", "median", "itr/sec", "n_gc")]

## # A tibble: 4 x 4
##   expression      min   median `itr/sec`
##   <bch:expr> <bch:tm> <bch:tm>     <dbl>
## 1 loop10       28.7us     32us    24857.
## 2 loop100      1.11ms   1.29ms      614.
## 3 vec10           7us    7.5us   112153.
## 4 vec100         49us   49.9us    17895.

random_string()을 통해 길이 50의 string을 원하는 만큼 만들고,
collapse()나 paste()를 이용해 한 줄로 바꾼다.
여기서 for문의 단점이 나타난다.
paste()는 100개짜리가 10개짜리보다 8배 정도 느렸던 반면,
for문에서는 약 30배 느렸다.
성능 생각한다면 for 반복문보다는 vectorized method를 사용하라는 게 이런 이유다.

결론

언제 복사가 일어날지 알아두고, 되도록 피하면서 코딩하자.