컴파일 체감 실행 속도야 원래부터 MiKTeX이 "조금" 느렸으므로 다시 말할 만한 것은 아니다. hangul-ucs MiKTeX 설치 파일을 테스트하느라고 MiKTeX을 설치해둔 Pentium 4 1.70GHz (512RAM) 기계(쫌 거시기한 컴퓨터라는 것은 인정한다...)에서 어젠가 오늘인가 업데이트가 있길래 유명한 자동 업데이트 툴을 이용하여 시스템을 갱신했다. 그런데... 문제는 여기서부터이다. 무슨 이유에선지는 모르겠으나 이제 업데이트 루틴의 일부로 Windows/Fonts 폴더를 읽어서 fontconfig cache를 갱신하는 루틴이 새로 생긴 것이다.[1] 시스템에 설치된 폰트가 조금 많다는 것은 인정한다만... 너무하다... 심지어 새로운 패키지 하나를 설치하면서도 꼬박꼬박 캐시를 갱신해준다니... 장난도 아니고... 그래서 subfigure 패키지 설치에 12분, xkeyval 패키지 설치에 물경 17분이 걸리고 있다.... 빠른 컴퓨터에서는 좀 나은지 모르겠으나, 패키지 설치 때마다 폰트 캐시를 새로 만든다는 것은... 정말 이상하다. 느린 컴퓨터에서 MiKTeX은 결코 small로 설치해서는 안되는 것이 되어 버렸다. 그러나 어차피 새로운 패키지가 나오면 또 저럴텐데...

여담이지만, 가상 DVD 드라이브에서 라이브로 돌리는 TeXLive보다 MiKTeX의 컴파일 속도가 느렸다. 그러잖아도 PDFTeX에서 트루타입 서브폰트 feature를 아예 (이유없이) 제외해버린 것 때문에 짜증나고 있던 참인데... MiKTeX은 내게는 적어도 "폭력적"으로 느껴진다.

생각건대, 폰트 폴더에 영문 폰트만 있다면야 속도 체감을 경험할 이유가 별로 없을 것이다. 그러나 한글/일어/중국어 폰트들이야말로 폰트 하나에 수십 메가가 넘는 공룡 폰트들인데 이걸 매번[2] 읽어서 캐시를 만든다면 얼마나 피곤한 일이겠는가? 트루타입 서브폰트 문제도 이걸 쓰는 게 거의 우리나 중국 정도뿐일 것이다. MiKTeX 2.6 베타 최신 버전에서 나는 우리나라 사용자들의 입장이 무시되었다고 느낀다.