Think about it.2011.10.19 20:33
시간 복잡도와 공간 복잡도 라는 개념이 있습니다.

프로그램의 알고리즘이 얼마나 시공간적인 최적화가 되었는지 확인 할수 있는 방법입니다. 복잡도가 0에 가까울수록 좋은 알고리즘이지요.

예전에 컴퓨터 사양지 좋지 못할때는 최적의 알고리즘으로 만들어야 했습니다. 물론 지금이라고 대충 만들면 된다는건 아니지만 지금은 어떻게 개발하던 작은 프로그램의 연산 속도는 비슷합니다. codeguru에서 이전에 While문이 빠른지 For문이 빠른지에 대한 아티클이 생각나네요 ^^

현재는 단순한 알고리즘이 문제가 아니라 수많은 자료형, 라이브러리, 프레임웍 사이에서 최적의 조합을 찾는것이 문제입니다.

예를 들면 빠른 응답속도의 웹페이지를 만들때 캐싱을 하냐 안하냐가 엄청난 퍼포먼스 차이를 보여줍니다. 하지만 실시간으로 변하는 데이터를 캐싱 하게 되면 단순히 플랫폼에서 제공되는 캐시로는 처리하기가 어렵습니다. 더군다나 대형 웹 사이트인 경우는 WebFarm 기반이라 캐싱된 데이터의 싱크문제도 있습니다. 이런경우는 캐쉬서버를 별도로 두어서 운영하는데 실시간 데이터의 무결성을 보장하려면 데이터가 변하는 액션이 있을때 마다 캐시데이터도 갱신 해주어야 합니다.

그렇다면 빠른 퍼포먼스를 위해 캐싱을 하기위해 캐쉬서버와 통신하는 코스트를 따진다면 결코 시공간 복잡성이 높아지고 소프트웨어 품질도 나빠집니다.

이런 경우라면 차라리 쿼리튜닝과 적절한 인덱스 설계로 응답속도를 줄일수 있을것 같습니다.

지금까지 수많은 코드를 짜면서 100% 만족하는 코드를 짤수 없었습니다. 항상 이 트레이드 오프가 걸렸기 때문이죠...

iPhone 에서 작성된 글입니다.
신고
Posted by dotnetpower

티스토리 툴바