'전체 글'에 해당되는 글 78건

리팩토링하면 소프트웨어가 느려질 수도 있는 건 사실이다. 하지만 그와 동시에 성능을 튜닝하기는 더 쉬워진다.

 

하드 리얼타임 시스템을 제외한 소프트웨어를 빠르게 만드는 비결은 먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것이다.

 

마틴은 빠른 소프트웨어를 작성하는 방법 세가지를 경험했다.

 

  • 시간 예산 분배 방식
    • 가장 엄격한 방법
    • 하드 리얼타임 시스템에서 많이 사용한다.
    • 설계를 여러 여러 컴포넌트로 나눠서 컴포넌트마다 자원(시간& 공간) 예산을 할당
    • 컴포넌트는 자원 예산을 초과할 수 없다.
    • 자원을 주고받는 메커니즘을 제공할 수는 있다.
    • 시간 엄수를 강조한다.
  • 끊임없이 관심을 기울이는 방식
    • 프로그래머라면 누구나 높은 성능을 유지하고 위해 무슨 일이든 한다.
    • 직관적이어서 흔히 사용하는 방식이다.
    • 실제 효과는 변변치 않다.
    • 성능을 개선하기 위해 코드를 수정하다 보면 프로그램은 다루기 어려운 형태로 변하기 쉽다.
    • 결국 개발 속도는 더뎌진다.

 

론 제프리 - 아무것도 안 만드는 데도 시간이 걸린다.

 

시스템에 대해 잘 알더라도 섣불리 추측하지 말고 성능을 측정해봐야 한다. 그러면 새로운 사실을 배우게 되는데, 십중팔구 내가 잘못 알고 있었음을 깨닫게 된다.

 

성능에 대한 흥미로운 사실은 대부분 프로그램은 전체 코드 중 극히 일부에서 대부분의 시간을 소비한다는 것이다. 그래서 코드 전체를 고르게 최적화한다면 그중 90%는 효과가 거의 없기 때문에 시간 낭비인 셈이다.

 

성능 개선을 위한 세 번째 방법은 "90%의 시간은 낭비"라는 통계에서 착안한 것이다. 즉, 의도적으로 성능 최적화에 돌입하기 전까지는 성능에 신경 쓰지 않고 코드를 다루기 쉽게 만드는 데 집중한다. 그러다 성능 최적화 단계가 되면 다음의 구체적인 절차를 따라 프로그램을 튜닝한다.

 

먼저 프로파일러로 프로그램을 분석하여 시간과 공간을 많이 잡아먹는 지점을 알아낸다. 그러면 성능에 큰 영향을 주는 작은 부분들을 찾을 수 있다. 그리고 그 부분들을 개선한다.

블로그 이미지

_김은찬

두번 다시는 꺾이지 않으리

,