gccemacs를 (당분간) 포기했다

gccemacs를 쓰는 것은 퍼포먼스 때문이었다. 해당 OS의 바이너리 포맷으로 컴파일하는 Native Compilation 기능은 당연히 바이트 컴파일만 된 스크립트보다 로딩 및 파싱이 빨라야 한다. 컴파일하는 시간이 오래 걸린다는 점을 제외하곤 모든 것이 좋으리라 생각했다.

macOS에서 gccemacs 설치하기(feat. emacs-plus)

물론 시작부터 단점이 있었다. 아직 Emacs 28 버전에서만 지원된다는 점이 있다.

그런데 이건 사실 별로 문제가 되지 않는다.

더 큰 문제는 어이없게도 로딩이 매우 느리다는 점이다. 아니 잠깐, 바이너리로 컴파일했다면 로딩이 압도적으로 빨라야 맞는 게 아닐까? 하지만 불행히도 내가 사용하는 설정인 Doom Emacs의 로딩은 Native Compilation 쪽이 수 배는 더 오래 걸렸다.

다만 로딩 문제는 Emacs 28이 아직 베타라 그럴지도 모른다.

그렇다고 하더라도 더 큰 단점을 찾게 되었다. 바로 바이너리 컴파일 그 자체의 문제 말이다.

728x90

어떤 상황에서 어떤 확장이 필요로 하는 외부 기능이 있다. 확장의 Elisp 코드에서 외부 패키지나 라이브러리를 가져와서 사용하는 경우다. 당연히 있을 수 있는 일이다. 다르게 표현하자면 컴파일된 스크립트에 외부 패키지 의존성이 생긴다는 말이다.

이 말은 의존성 패키지를 삭제하거나 업그레이드 하는 등 의존성이 깨지게 되면 그걸 링크해서 사용하던 바이너리는 에러가 발생한다는 말이 된다. 실제로 나는 brew upgrade 명령을 실행한 후 내 Emacs의 몇몇 명령이 오류를 일으키는 경우를 종종 봐왔다. 라이브러리를 못 찾거나 별도의 에러가 있거나 나타나는 증상은 다양했지만 어쨌든 결과적으로 에러로 이어졌다.

결국 brew upgrade 명령을 쓸 때는 긴장을 하게 될 수밖에 없었다. 그러다 문제가 생기면 해당 확장만 삭제하고 다시 빌드하거나 혹은 원인을 못 찾아서 Doom Emacs 자체를 완전히 새로 설치하기도 했다. 물론 시간은 시간대로 버리고 말이다.

지나친 긴장은 당연히 스트레스를 유발한다. 불행히도 생각보다 자주 의존성 패키지 업데이트가 올라왔다. 이 잦은 스트레스를 참으며 견디며 순응하는 것이 맞는 것일까? 아니면 포기하는 것이 더 유익한 행위일까?

나는 포기하기로 했다.

brew uninstall emacs-plus@28
brew cleanup
brew install emacs-plus

마음에 안 들게 튜닝된 도구에 순응하는 것은 그다지 유쾌하지 않은 것 같다. 그래서 모든 것을 기본 상태로, 모든 것을 안정 버전으로 다시 돌아가기로 했다. 아직 Emacs 안정 버전은 27.2다. 당연히 Native Compilation은 지원되지 않는다.

사실 내 Emacs의 시작 화면은 빈 화면이지만 썰렁한 것 보단 이게 나을 것 같다

효과는 굉장했다. 굉장히 속이 편해졌다. 그것뿐인가. 로딩 속도도 무지 빠르다. 말 그대로 개빠르다. Doom Emacs의 설치 및 빌드 속도도 엄청나게 빨라졌다.

그리고 대망의 실제 사용 퍼포먼스는 의외로 달라진 것이 없게 느껴졌다. 혹시 나는 gccemacs를 잘못 사용하고 있었던 것일까? 그렇다 할지라도 너무나 쾌적하게 느껴졌다.

Native Compilation 기능이 곧 메인에 들어갈 것이라는 소식이 들리기도 한다. 많이 안정화가 되어가나 보다. 그렇다고 할지라도 내가 과연 다시 Native Compilation을 사용할까는 아직 의문 투성이다. 바이너리 컴파일의 단점이라는 쓴 맛을 보았더니 이렇게 가치관이 바뀌게 되는 것이 신기하기도 하다.

이제는 관심이 좀 바뀌어서 emacs-ng를 기대하고 있다. 과연 어떤 것을 보여줄 것인가 두든 두근 한다.

관련 링크

gccemacs