Refactoring과 Optimization

이번 글에서는 refactoring이 어떻게 optimization에 도움을 주는지 알아보도록 하겠습니다. 아래 코드와 같이 극단적인 예를 사용해서 말이죠. :-)

다섯개의 함수가 있습니다. func1과 func3는 주어진 수까지의 짝수의 합을 출력하고 func2와 func4는 홀수의 합을 출력합니다. func5는 하나의 루프에서 둘 다를 계산한 후 출력하고요.

void func1(int cnt) {
  int e_sum = 0;
  for (int i = 0; i < cnt; ++i) 
    if (i % 2 == 0) e_sum += i;
  printf("%d\n", e_sum);
}

void func2(int cnt) {
  int o_sum = 0;
  for (int i = 0; i < cnt; ++i) 
    if (i % 2 == 1) o_sum += i;
  printf("%d\n", o_sum);
}

void func3(int cnt) { // same as func1
  int e_sum = 0;
  for (int i = 0; i < cnt; ++i)
    if (i % 2 == 0) e_sum += i;
  printf("%d\n", e_sum);
}

void func4(int cnt) { // same as func2
  int o_sum = 0;
  for (int i = 0; i < cnt; ++i)
    if (i % 2 == 1) o_sum += i;
  printf("%d\n", o_sum);
}

void func5(int cnt) {
  int e_sum = 0;
  int o_sum = 0;
  for (int i = 0; i < cnt; ++i) {
    if (i % 2 == 0) e_sum += i;
    else o_sum += i;
  }
  printf("%d\n", e_sum);
  printf("%d\n", o_sum);
}

위의 코드를 refactoring하면 다음과 같이 되겠죠. 여기선 Extract Method를사용했습니다.

void e_sum(int cnt) {
  int e_sum = 0;
  for (int i = 0; i < cnt; ++i) 
    if (i % 2 == 0) e_sum += i;
  printf("%d\n", e_sum);
}

void o_sum(int cnt) {
  int o_sum = 0;
  for (int i = 0; i < cnt; ++i) 
    if (i % 2 == 1) o_sum += i;
  printf("%d\n", o_sum);
}

void func1(int cnt) {
  e_sum(cnt);
}

void func2(int cnt) {
  o_sum(cnt);
}

void func3(int cnt) { // same as func1
  e_sum(cnt);
}

void func4(int cnt) { // same as func4
  o_sum(cnt);
}

void func5(int cnt) {
  e_sum(cnt);
  o_sum(cnt);
}

위의 코드를 보면 대부분의 반응은 "어라~ func5는 이전 코드에선 loop를 한번만 돌았는데 이젠 두번을 돌잖아. 역시 refactoring은 성능엔 좋지 않군." 정도일 겁니다. 하지만 이런 반응의 문제는 너무 라인 레벨의 micro 성능에 대해서만 생각하고 있다는겁니다.

대부분의 성능 관련 문제도 pareto 원칙이라는 80-20 rule을 따릅니다. 즉, 대부분의 bottleneck은 전체 코드의 20%에서 발생하고 성능을 개선하기 위해선 이 20%을 찾아 개선해야 한다는 얘기지요.

그럼 첫번째, refactoring 전의 코드가 성능 조건을 만족시키지 못한다고 가정하고 문제의 20%가 어딘지를 찾기 위해 profiler를 해보죠. 아래 내용이 gprof를 사용하여 첫번째 코드를 profiling한 결과입니다.

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 25.93      0.42     0.42        1   420.00   420.00  func2(int)
 24.07      0.81     0.39        1   390.00   390.00  func5(int)
 22.84      1.18     0.37        1   370.00   370.00  func4(int)
 15.43      1.43     0.25        1   250.00   250.00  func3(int)
 11.73      1.62     0.19        1   190.00   190.00  func1(int)

보시다시피 대부분의 함수가 비슷한 시간을 사용하고 있기 때문에 어디가 80-20 rule의 20%인지 알기 어렵습니다. 그래도 일단 위쪽의 함수들이 문제가 있다고 판단하고 처음 두개 함수의 성능을 두배 향상시켰다고 해보죠. 그럼 20+20+20+20+20=100%에서 10+10+20+20+20=80%가 됩니다. (여기선 각 함수가 거의 똑같은 작업을 하므로 각각 20%씩을 사용한다고 가정하고 계산했습니다.)

약 20%의 성능이 개선된 것이죠.

그럼 refactoring한 후의 코드를 profiling해보죠. 아래 내용이 그 결과입니다.

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 61.58      1.25     1.25        3   416.67   416.67  o_sum(int)
 38.42      2.03     0.78        3   260.00   260.00  e_sum(int)
  0.00      2.03     0.00        1     0.00   260.00  func1(int)
  0.00      2.03     0.00        1     0.00   416.67  func2(int)
  0.00      2.03     0.00        1     0.00   260.00  func3(int)
  0.00      2.03     0.00        1     0.00   416.67  func4(int)
  0.00      2.03     0.00        1     0.00   676.67  func5(int)

극단적인 예를 사용하여 결과가 좀 노골적이긴 ;-) 하지만 위의 두 함수를 골라 역시 성능을 두배 향상시켰다고 해봅시다. 그럼 50+50=100%에서 25+25=50%가 됩니다.

.
.
.

위의 예와 같이 코드가 제대로 refactoring되지 않아 여기저기 중복되어 있다면 실제 20%의 bottleneck을 찾기란 매우 어렵습니다. 이렇게 profiling을 통해 찾을 수 없게 되면 결국 코드를 읽고 그 20%를 추측하게 되는데 대부분 잘 맞질 않죠.

몇년전 제 경험을 들어보죠. 성능이 약 5%가 부족했습니다. 5,000,000 BHCA를 해야 했는데 약간 모자랐죠. 그래서 이것저것 눈에 보이는 문제들을 수정해보았으나 소득이 별로 없었습니다. 결국 profiling을 해보기로 하고 Rational사의 quantify를 사용했습니다. 처음 profiling이라는 것을 해볼 기회였기에 기대가 컸죠. 하지만 결과는...

정확히 기억나진 않지만 대부분의 함수가 1%미만이었습니다. 물론 훨씬 더 대부분은 0.1%이하였죠. 기억에 제일 윗줄을 장식했던 것은 std::string의 어떤 함수였던것 같습니다. 이 결과를 두고 이런 말도 나왔죠. "그러게... std::string 쓰면 성능이 안좋아진다니까." :-| ((이전 Core Dump Pattern?의 예도 std::string에서 core가 보이기 때문에 비슷한 말이 나옵니다. "std::string쓰면 자꾸 죽는다니까.")) 0.1%짜리 함수 50개를 아예 없애야 5%가 됩니다. :-(

그래도 이때는 여러 편법을 동원해서 간신히 성능을 맞출 수 있었습니다. ((여기서 편법이란 주로 성능 시험에선 사용하지 않는 기능들을 임시로 삭제하는등의 방법이었죠. 눈가리고 아옹이랄까? :-| 이후 platform을 SUN에서 Intel로 바꾼후 성능이 약 5~10배 향상되어 성능 문제는 잠시 없어졌었습니다만 곧 다시 등장했습니다. 이전 SUNSparc에서 30개의 보드를 가지고 하던 일을 Intel에서는 4개의 보드만을 가지고 해야 했거든요. :-) ))

제 생각엔 대부분의 PC용 프로그램들은 아예 성능 문제라는게 없을 것 같습니다. 따라서 성능보단 refactoring을 통한 깔끔한 코드를 더 중요시하죠.

하지만 네트웍이든 데이터든 대용량의 서비스를 해야 하는 프로그램들이라면 성능에 좀 더 민감합니다. 이 경우엔 refactoring을 통한 깔끔한 코드보단 성능 문제가 없을 것으로 보이는 코드를 작성하기 쉽습니다. (위의 func5와 같이 말이죠. 일종의 premature optimization입니다.) 하지만 이 경우에도 위의 예로 본바와 같이 refactoring한 코드가 optimization 단계에서 훨씬 큰 성능 향상을 가져옵니다. 지난번 글에서도 썼지만 오늘의 주제는.

Don't optimize prematurely. Prefer clean code with refactoring to premature optimized one.

입니다.

아! 물론 이것도 잊지 마세요.

Don't pessimize prematurely. ((C++ Coding Standards, Chapter 9 참조))