TL; DR 엄청난 양의 패키지가있어서 시작 시간을 아프게합니다. 그럴 수 있다고 생각하지 않으면 계속 읽으십시오.
나의 Emacs 시작 시간은 매우 작습니다. 나는 사용하지 않고 use-package, autoload거의 모든 코드가 연기되도록 많은 후크와 s를 설정 했다. 실제로 모든 것이 미친 혼란처럼 보이지만 일반적으로 0.5 초 미만으로로드됩니다.
그러나 시간이 지남에 따라 시작 시간이 약간 느려져 설명 할 수없는 것으로 나타났습니다 . 결국 시작 시간이 1 초 이상인 지점에 도달했습니다. 나는 마침내 충분했고 문제의 근원을 파헤 쳤다. 결국 전체 ~/.emacs파일을 주석 처리하고 시작 시간이 여전히 1 초 이상 임을 알았습니다 . 실제로, 그것은 ~ 0.2초만 면도하고 때로는 더 적게 면도했습니다 . 그런 다음 emacs -q시작 시간이 ~ 0.1초라 는 것을 알았 습니다.
검사시 이 부분 Elisp 매뉴얼을, 나는 이유를 발견 emacs -q너무 많은 시작 시간을 단축했다. 분명히 emacs -q시작할 때 세 가지 일을에서 이맥스를 중지 :
- init 파일로드
default.el파일 로드- 부름
package-initialize
우리는 이미 init 파일을 모두 배제했습니다 ~/.emacs. 나는 default.el파일을 사용하지 않으므로 배제됩니다. package-initialize성능 히트의 범인으로 남습니다 .
package-initialize시작 시간이 너무 많은 이유는 무엇 입니까? 그게 내가 물었던 첫 번째 질문이었습니다. 모든 것을 자동로드하지 않습니까? 그래 그러나 그것은 정확히 문제입니다.
“활성화”패키지가 자동로드 파일 읽기 및로드 경로 설정으로 구성되어 있음을 설명하는 이 게시물 을 찾았 습니다 . 읽을 수있는 많은 자동로드 파일과 설정해야 할 경로가 많기 때문에 패키지가 많은 경우 분명히 I / O 패널티가 발생합니다. 불행히도, 이것이 없으면 자동로드 관리 작업이 사용자의 손에 달려 있습니다. 즉, package.el파일 시스템을 자동로드 파일 및 경로로 크롤링 하지 않으면 지루하고 오류가 발생하기 쉬운 프로세스를 직접 관리해야합니다.
나는 그 길로 내려 가지 않는 것을 선호합니다. 현재 116 개의 패키지가 있으며 ELPA의 패키지 중 107 개와 종속성 중 25 개가 있습니다. 이 엄청난 숫자가 내 성능을 심하게 저하시키는 요소라고 확신합니다. 그러나 패키지를 제거하고 싶지 않기 때문에 나는 일시적입니다.
이러한 상황에서 번개가 다시 시작되는 시간에 구제책이 있습니까?
최신 정보:
이 문제를 해결하기 위해 메일 링리스트 에서 Stefan Monnier의 일부 패치 (이 패치에 대한 설명은 here ) 에 대한 새로운 스레드 를 시작했습니다 . 누구나 패치를 테스트하고 피드백을 제공 할 수 있습니다.emacs-devel
또 다른 업데이트 :
Stefan Monnier가 더 이상이 문제에 관심이 없거나 내 메시지를받지 못하는 것 같습니다. 나는 전자를 믿는 경향이 있습니다. 그렇다면 괜찮습니다. 그의 경우에는 그에게서 어떤 반응을 보일 것입니다. 어쨌든,이 문제에 대해 그가 작성한 코드는 꽤 잘 작동합니다. 그의 최신 패치는 여기 (Emacs 25.3) 와 여기 (Emacs 마스터 브랜치) 에서 찾을 수 있습니다 .패치 덕분에 시작 시간이 크게 향상되었으며 시작 시간에 익숙해 져서 사용자 지정 기능을 없애지 않고도 최대한 최적화 된 시점에 있습니다. 나는이 패치들이 언젠가는 이맥스 메인 라인으로 만들어지기를 바랐지만, 나는 스테판 대신에 지금이나 다른 누군가가 그것을 위해 횃불을 가져 가야한다고 생각한다. 우리는 메일 링리스트에 저작권 할당 및 라이센스에 관한 약간의 스파를 가졌습니다. 처음에는 그렇게하는 것이 불편했지만 Richard Stallman과 다른 사람들의 의견으로 인해 저작권 할당이 원래 생각했던 것만 큼 제한적이지 않을 수 있습니다. 또한 저의 저작물을 저작권 할당의 대안으로 퍼블릭 도메인에 커밋 할 수 있습니다.
어쨌든, 지금까지 패치에 대해 Stefan에게 감사드립니다! 이러한 변화를 계속 발전 시키길 희망하지만, 그렇지 않다면 괜찮아 어느 시점에서 계속 발전 할 수 있습니다. 이 문제를 해결하는 데 통찰력과 기여를 한 다른 모든 분들께도 감사드립니다.
또 다른 업데이트 :
와우,이 기능은 마침내 도착했고 Emacs 27에있을 것 같습니다 . Stefan Monnier에게 감사합니다!
답변
package.el의 디자인 선택 중 하나는 “간단한”작업을 시도하는 것이 었습니다. 이것의 일부 package-initialize는 설치된 모든 패키지 를 검색 한 다음 (동일한 패키지의 여러 버전이 사용 가능한 경우 고정 및 버전의 최신성에 따라) 활성화해야 할 패키지를 파악한 다음로드하는 것입니다 각각은 패키지 <pkg>-autoloads.el파일을 활성화 합니다.
따라서 N 설치된 패키지의 경우 기본적으로 N <pkg>-pkg.el패키지 설명 파일과 N <pkg>-autoloads.el파일을 읽습니다 . 큰 N의 경우 심각한 문제가 될 수 있습니다. 또 다른 잠재적 인 성능 문제는 N 요소를에 추가한다는 것입니다 load-path. 따라서 loadEmacs가 N 디렉토리를 검색 할 때마다 각각 load느려집니다.
우리가 이것을 가속화하고 시도 할 수있는 다양한 방법이 있습니다 :
-
올바른 순서로
~/.emacs.d/elpa/package-initialize.el(c)모든 권리를 연결 한 결과 파일 을 미리 계산할 수있는 방법을 제공하십시오<pkg>-autoloads.el. 그런 다음package-initialize이 파일이있을 때이 파일을로드하고 다른 모든 것을 건너 뛸 수 있습니다. 그런 다음package-initialize.el(c)패키지를 추가 / 업데이트 / 제거하거나 또는를 변경하면 파일 을 새로 고치거나 플러시 할 수있는 방법이 필요package-pinned-packages합니다package-load-list. 시스템을 거의 변경하지 않고도이 작업을 수행 할 수 있다고 생각합니다 (실제로 변경 해야하는 유일한 방법package-initialize은 사용 가능한 패키지에 대한 메타 데이터를로드하지 않고 “활성화 만”하도록 지시 할 수 있음). -
슈퍼 패키지 하나에 여러 패키지를 결합, 즉 패키지를 조작 / 빌드 할 수있는 방법을 제공합니다 (그래서에 추가 된 하나의 요소가있어
load-path하나<pkg>-pkg.el하나의<pkg>-autoloads.el로드가). 이렇게하는 것이 더 어려울 수 있습니다 (따라서 그러한 슈퍼 패키지에 포함 된 패키지의 일부만 활성화 할 수 없으므로 종속성 / 버전 분석이 까다로울 수 있습니다).
위의 첫 번째 옵션은 구현하기가 쉬우 며 많은 패키지가 설치되어 있으면 package-initialize 훨씬 빨라집니다. 시도해보고 싶으시면 언제든지 도움을 요청하십시오.
FWIW, 방금 테스트 설정에서 “수동으로”메가 자동로드 파일을 만들려고했습니다. 결과 : package-initialize약 0.9 초가 걸리지 만 mega-autoloads.el파일을 로드하는 데 0.3 초가 걸리므 load-source-file-function로 nil에 바인딩 하여 0.2 초, 파일 을 바이트 컴파일하면 0.1 초로 줄일 수 있습니다 . 나는 정직하게 더 나은 속도를 기대했지만 여전히 가치가 있습니다.
[편집]이 “메가 오토로드”접근 방식은 이제 Emacs의 마스터 브랜치에서 사용할 수 있습니다 (먼 장래에는 Emacs-27이되기 위해). 새로운 package-quickstart변수에 의해 제어됩니다 .
답변
당신에 대해 설명하는 문제를 package-initialize부하에 너무 많은 시간을 복용은 잘 알려진 문제입니다. 또한 일부 emacs 프레임 워크가 자동로드를 수동으로로드하여 해결하려고하는 문제 중 하나입니다.
문제에 대한 두 가지 해결책이 있습니다.
- 경로를 설정하고 관심있는 패키지의 자동로드를로드하는 기능을 작성하거나 프레임 워크에서 추출하십시오.
- 속도를 명시 적으로 목표로하는 프레임 워크를 사용하십시오. 나는 개인적으로 DOOM emacs를 추천 합니다. 이 프레임 워크를 사용하면 약 1 초 안에 200 개가 넘는 패킷을로드합니다.
DOOM emacs를 권장하는 주요 공명 중 하나는 프레임 워크가 패키지 관리를 emacs 외부에 두는 것입니다. 나를 잘못 해석하지 마라. 여전히 패키지 관리를하는 것은 emacs이며, 단지 패키지 관리가 표준 사용자 세션 외부에서 수행된다는 것입니다. 여기서의 철학은 다음과 같습니다. 일반적으로 emacs를 시작할 때 모든 패키지가 있고 이미로드되어 있다고 가정 할 수 있습니다. 이것은 많은 시간을 절약합니다. DOOM emacs는 emacs와 동등한 apt-get또는 이맥스를 제공합니다 pacman. 일단 패키지가 설치되면 emacs가 시작될 때마다 이미 설치된 것으로 가정합니다. 질문이 없습니다.