결국... 모듈화가 덜 된 현재 상태에서 dispatcher로 바로 갈아타기는 무리라는 판단에 어제까지의 trunk를 흑역사(...)로 분기시키고 다시 엎었습니다. 제주도 호텔에서 밤새 삽질하고 서울 올라와서 오프미팅하면서 얻은 결론...이었죠.지난 일주일 동안 깨달은 것은 inureyes님과 함께 2.0 프레임웍 구조 도입을 시도하면서 텍스트큐브 1.7까지의 기존 구조가 성능 면에서는 꽤 유리하다는 점이었습니다. interface에서 초기화 코드가 들어있는 파일들을 직접 부르도록 함으로써 중복코드도 생기고 코드 추적은 어려워진다는 단점이 있지만 덕분에 초기화 전에 각 interface에서 미리 체크해야 할 것들(input validation이나, 아이콘 핸들러인 경우 해당 처리만 하고 초기화하지 않고 끝내기 등)을 수행할 수 있었기 때문입니다.
우선은 현재 가장 큰 오버헤드가 큰 요소 중 하나인 includeFor*.php를 모두 autoload로 대체해야 하는데, 이렇게 해서 얻을 수 있는 성능 향상이 얼마나 될지는 아직 알 수 없습니다. 필요한 클래스만 불러온다 해도 URL 해석기를 쪼개든지 interface를 쪼개든지 해야 dispatcher에 전체 흐름 코드를 모아둔 상태로 성능 최적화가 가능한데, 쪼갠다는 것 자체가 php에서는 새로운 파일을 만드는 것과 같아져서 오버헤드가 증가하기 때문입니다. (지금까지는 require/include를 통해 'jump'해다니는 개념이었다면, 앞으로는 dispatcher만 보면 모든 실행 흐름을 한 눈에 볼 수 있도록 할 생각입니다) 게다가 이미 인터페이스 종류에 따라 불러와야 할 파일들을 따로 나누어 처리하고 있기 때문에 autoload에 의한 최적화를 하더라도 클래스 불러오는 시점만 달라질 뿐 결국 전체 불러오는 양에는 큰 차이가 없을 수도 있습니다.
하여간 이런저런 문제로 마구 갈아엎다보니 trunk가 좀 난장판(...)이 되었다는 게 결론;; orz
ps. 이런 고민을 막 하다보면, 과연 지금 생각하고 있는 2.0 추상화 구조가 php 언어에 적합하지 않은 것일지도 모르겠다는 생각마저 듭니다. namespace조차 없는 언어에서 하려니 어려움이 많군요. 확 python으로 갈아타고 싶습니다. ㅠ_ㅠ 2.0 성능 최적화를 위해 나온 아이디어를 중 상당수가 사실 django에서 이미 다 제공하는 거라는 거...
]]>
