W jaki sposób Emacs potrafi natychmiast zacząć od wielu plików el?

Jak każdy Emacs'er się dowie, obecnie cierpię z powodu mojej rozległej konfiguracji dot-Emacsa. Wszystkie moje paczki znajdują się w kontenerach use-packagei skompilowałem bajtami wszystkie moje .elpliki. Mimo to Emacs uruchamia się za 6,4 sekundy, a następnie ładuje resztę pakietów (około 40).

Myślałem o innym sposobie rozwiązania długiego czasu uruchamiania, ale zauważyłem coś. Domyślny Emacs (bez konfiguracji użytkownika) korzysta z wielu .elbibliotek, które są dołączone do każdego Emacsa. Znajdują się w \shares\emacs\version number\lisp\.

Nawet przy wielu plikach lisp udaje się rozpocząć w ciągu jednej sekundy. Kiedy sprawdzałem pliki wielu pakietów, które są dołączone do domyślnego Emacsa, nie znalazłem nic nadzwyczajnego, co mogłoby wyjaśnić, dlaczego Emacsowi udało się uruchomić w ciągu jednej sekundy. Czy ktoś mógłby mi powiedzieć, jak Emacs sobie z tym radzi, nawet z tysiącami .elplików?

Czy ktoś mógłby mi powiedzieć, jak Emacs sobie z tym radzi, nawet z tysiącami plików .el?

Emacs „zarządza” tym, że nie ładuje się przy starcie, a tym samym nie wstrzymuje ładowania podstawowej aplikacji. To z kolei jest efektem szybszego zwracania użytkownikowi kontroli nad klawiaturą.

Ale kiedy jest załadowany? Przy pierwszym użyciu tej funkcji, trybu lub funkcji.

Czy to nie zwalnia? Tak, przy pierwszym użyciu. To jest kompromis. Czy chcesz zwolnić podczas uruchamiania emacsa czy przy pierwszym użyciu?

Czy to zauważalne? Ładowanie podczas uruchamiania wydaje się trwać dłużej, ponieważ ładowane są również inne biblioteki podstawowe. Ale przy pierwszym użyciu wydaje się szybszy, ponieważ ładowana jest tylko ta funkcja podzestawu.

Dlaczego więc ktoś miałby ładować przy starcie? Ponieważ niektórym nie przeszkadza czekanie na załadowanie wszystkich często używanych bibliotek podczas uruchamiania, więc po załadowaniu wszystkie operacje są wykonywane szybko.

Jak mogę wybrać? Jak Drew i inni wskazali w swoich odpowiedziach na to pytanie, możesz użyć automatycznego ładowania i podobnych sztuczek, aby kontrolować. Ale najważniejszym czynnikiem powinien być wzorzec użytkowania. Jeśli zdarzy ci się używać emacsa, takiego jak vi, ciągłe otwieranie i zamykanie, tak, czas uruchamiania staje się boleśnie oczywisty. Ale z drugiej strony, jeśli używasz emacsa działającego cały czas, czas uruchamiania 1 sekundy lub 1 minuty nie będzie tak zauważalny ani wystarczająco ważny, aby się tym przejmować.

Uwaga: możesz użyć trybu wsadowego lub Zile do natychmiastowego uruchomienia podczas testowania, uruchamiania lub w inny sposób za pomocą emacsa, takiego jak vi.

Preferuję ładowanie przy starcie, aby wszelkie błędy były wychwytywane z góry. Wolę nie mieć do czynienia z błędami ładowania w środku dnia roboczego, gdy mam niezliczoną liczbę buforów, trybów i stanów kompilacji oraz kilka zdalnych lokalizacji zarządzanych przez TRAMP. Debugowanie błędów autoloadowania w takich warunkach nie jest zbyt przyjemne.

Wiele dołączonych bibliotek nie jest ładowanych podczas uruchamiania.

Niektóre polecenia itp. Są ładowane automatycznie , co oznacza, że ​​Emacs je rozpoznaje i wie, jak je załadować. Podczas próby użycia polecenia, które jest ładowane automatycznie, Emacs ładuje bibliotekę, która go definiuje, jeśli nie została jeszcze załadowana.

Możesz tworzyć własne autoloady, zarówno dla własnych poleceń, jak i poleceń w bibliotekach, których nie napisałeś. Zobacz instrukcję Elisp, węzeł Autoload .

Oprócz innych odpowiedzi (które wyjaśniają, w jaki sposób większość bibliotek jest ładowana tylko na żądanie), istnieje również kwestia wstępnego ładowania wielu podstawowych bibliotek elisp w samym emacspliku wykonywalnym, co daje złudzenie, że ładuje wiele rzeczy niesamowicie szybko.

Osiąga się to poprzez uruchomienie tak zwanej „gołej” wersji Emacsa (która została faktycznie skompilowana i która jest w pełni funkcjonalna, ale zawiera tylko interpreter elisp i inne podstawowe funkcje napisane w C) i nakazuje załadowanie wszystkie biblioteki elisp, które powinny zostać wstępnie załadowane, zanim w końcu „wyrzucą” rzeczywisty emacsplik binarny za pomocą wbudowanych bibliotek.

Mechanizm ten jest szczegółowo opisany w instrukcji elisp:
C-hig (elisp) Building Emacs RET

Jeśli sam skompilowałeś Emacsa, możesz eksperymentować z tym procesem, a nawet zrzucić alternatywne wersje ostatecznego pliku wykonywalnego, jeśli chcesz (ogólnie nie jest to zalecane, ale narzędzie jest dostępne).

Skompilowany temacsplik binarny można znaleźć w srckatalogu, a różnicę czasów rozpoczęcia można porównać, uruchamiając każdą wersję w następujący sposób:

$ time ./temacs -l loadup --batch
$ time ./emacs --batch

W moim systemie pierwsze zajmuje ~ 4 sekundy (podczas których ładowanych jest 111 bibliotek elisp), a drugie zajmuje około 0,02 sekundy.