. 그 외의 최적화

이 외에도 최적화의 대상이 될만한 부분은 아직도 많이 남아 있다. 어떤 부분이 더 최적화될 수 있는지 몇 가지 후보들을 정리해보도록 하자.

 

줄 정보 갱신 : UpdateLineInfo 함수는 문서 전체의 줄정보를 항상 완전히 다시 작성하는데 문서 끝 부분을 편집할 때는 그럴 필요가 없다. 무효영역을 최소화했듯이 줄 정보를 갱신할 범위도 최소화하면 편집속도가 많이 향상된다.

한글조립중의 임시 변경 : 한글이 조립되고 있는 중에도 Insert Delete가 호출되는데 이때는 글자가 제자리에서 바뀌기만 할 뿐 실제로 문자가 늘어나는 것은 아니다. 이때 UpdateLineInfo, UpdateScrollInfo 호출은 생략해도 상관없다.

lstrlen(buf) : 문서의 길이를 계산하는 이 호출문은 문서가 커지면 느려질 수 있다. 문서의 총 줄수를 TotalLine에 기억시켰듯이 총 크기도 별도의 변수에 저장한다면 매번 버퍼 길이를 계산하지 않아도 된다.

이분 검색 : GetRCFromOff는 오프셋으로부터 행렬값을 계산하기 위해 pLine 배열을 사용한다. 이 배열은 크기순으로 정렬되어 있으므로 순차 검색 대신 이분 검색을 하면 훨씬 더 빠른 검색을 할 수 있다.

 

대표적인 몇 가지 최적화 대상만 정리해 봤는데 어디 이뿐이겠는가? 이 최적화들도 힘들여 하게 되면 속도의 향상은 분명히 있으며 머지 않아 해보게 될 것이다. 최적화는 많이 하면 할 수록 좋은 것이다. 하지만 ApiEdit6는 이 수준까지만 최적화를 하고 나머지는 다음 기회로 미루기로 한다.

왜냐하면 이 예제는 아직 한참 만들어지고 있는 중이고 모든 기능이 완전히 정립된 것이 아니기 때문이다. 최적화는 항상 개발 단계의 제일 끝에 있어야 한다. 최적화를 한 상태는 그렇지 않은 상태보다 코드가 더 복잡해져 있고 또 논리가 직선적이지 않아 이 상태에서 기능을 확장하기가 쉽지 않다. 또한 최적화의 기법 자체가 아주 특수한 조건을 교묘하게 이용하는 것이 많은데 기능이 확장되면 그 조건이 사라질 수도 있기 때문에 미리 최적화를 하는 것은 여러 모로 불리하다.

프로그래밍에서 최적화는 바둑의 끝내기에 해당한다. 큰 집을 다 차지하고 난 다음에 한 집이라도 더 벌기 위해 바둑돌을 놓는 것처럼 최적화도 큰 기능을 다 만들고 난 후에 마지막 속도 향상을 위해 코드를 수정하는 작업이다. 바둑 중반부터 한 집에 미련을 버리지 못하고 끝내기에 집착한다면 그 바둑은 절대로 이길 수 없다.

여기서 한 작업은 최적화라기 보다는 이후의 기능 확장을 위한 구조 수정이라고 하는 것이 옳을 것 같다. ApiEdit6는 기능면에서 단 하나도 추가된 것은 없지만 훨씬 더 논리적으로 치밀해졌고 확장성이 좋아졌다. 여기에 만족하고 다음 실습부터 또 편집기를 위한 다양한 기능을 작성해보도록 하자. 다음 실습으로 넘어가기 전에 속도 측정을 위해 작성한 SpeedTest 임시 함수와 OnCreate의 파일 입력 코드는 삭제하도록 하자.