Birçok pakete rağmen başlatma süresini nasıl geliştirebilirim?


19

TL; DR Başlangıç ​​zamanımı incitecek kadar büyük paketlerim var. Durumun böyle olabileceğine inanmıyorsanız, okumaya devam edin.


Emacs'ımın başlama süresi oldukça az. Kullanmıyorum use-package, sadece tonlarca kanca ve autoloads ayarladım, böylece neredeyse tüm kodlar ertelendi. Gerçekte, her şey çılgın bir karmaşa gibi görünse de, genellikle yarım saniyeden daha az bir sürede yüklenir.

Ancak, zaman içinde benim başlangıç zamanı alır fark inceden açıklanamaz, yavaş. Bu sonunda başlangıç ​​zamanının ≥ 1 saniye olduğu noktaya geldi. Sonunda yeteri kadar yaşadım ve sorunun kökünü araştırdım. Sonunda tüm dosyama yorum yaptım ~/.emacsve başlangıç ​​zamanının hala ≥ 1 saniye olduğunu gördüm . Aslında, sadece 0.2birkaç saniye, bazen daha da az tıraş olmuştu . Sonra denedim emacs -qve başlangıç ​​zamanının ~ 0.1saniye olduğunu buldum .

Elisp kılavuzunun bu bölümünü inceledikten sonra , emacs -qbaşlatma süresini neden bu kadar azalttığını öğrendim . Görünüşe göre emacs -qEmacs'ın başlangıçta üç şey yapmasını engelliyor:

  1. init dosyanızı yüklemek
  2. default.eldosyanızı yüklemek
  3. çağrı package-initialize

Tüm dosyama yorum yapmak ~/.emacsneredeyse hiçbir şey yapmadığından , init dosyamı zaten dışlamıştık . Bir default.eldosya kullanmıyorum , bu yüzden de reddedildi. Hangi package-initializeperformans hit için suçlu olarak bırakır .

Neden package-initializebu kadar başlangıç ​​zamanı alıyor? Kendime sorduğum ilk soru buydu. Her şeyi otomatik olarak yüklemiyor muyum? İyi evet. Ama bu tam da bir sorundur.

Bulduğum bu yazı paketleri "aktive" özdevinimli_yükle dosyaları okuma ve yük yolları ayar oluştuğunu açıklar. Bu, çok sayıda paketiniz olduğunda açık bir G / Ç cezasına neden olur, çünkü okunacak çok sayıda otomatik yükleme dosyanız ve ayarlamanız gereken birçok yol vardır. Ne yazık ki, bu olmadan, otomatik yükleri yönetme görevi kullanıcının eline düşer. Başka bir deyişle, package.elotomatik yükleme dosyaları ve yolları için dosya sistemini taramaya izin vermeden , sıkıcı ve hataya açık bir süreç olabilecek kendimi yönetmem gerekir.

O yoldan aşağı gitmemeyi tercih ederim. Şu anda 116 paketim var ve 107 tanesi ELPA'dan ve 25 tanesi bağımlılık. Eminim bu okkalı sayı performansımı bu kadar kötüleştiren şeydir. Ancak bir pakette varım çünkü paketlerimin hiçbirini kaldırmak istemiyorum.

Böyle bir durumda yıldırım açılış zamanımı geri almak için herhangi bir çözüm var mı?


Güncelleme:

Biz başladık yeni bir iş parçacığı üzerinde emacs-develyaklaşık posta listesine bazı yamalar tarafından Stefan Monnier'in (bu yamalar tanımıdır burada bu sorunu çözmek için). Herkes yamalarını test edebilir ve geri bildirimde bulunabilir.

Başka bir güncelleme:

Görünüşe göre Stefan Monnier artık bu konuyla ilgilenmiyor ya da mesajımı almıyor. İlkine inanmaya meyilliyim, ki bu iyi, ama eğer durum buysa, ondan bir tür cevabı takdir ediyorum. Her neyse, bu konu için ürettiği kod oldukça iyi çalışıyor. En son yamaları burada (Emacs 25.3 için) ve burada (Emacs ana dalı için) bulunabilir.Yamaları sayesinde başlangıç ​​zamanımda iyi gelişmeler gördüm ve başlangıç ​​zamanımdan, özelleştirmemin özelliklerini kesmeden olabildiğince optimize edildiği için rahat olduğum bir noktadayım. Bu yamaların bir noktada Emacs ana hattına girmesini umuyordum, ama sanırım ben (ya da başka birisinin) bunun yerine meşale almak zorunda kalacaktım, Stefan yerine. E-posta listesinde telif hakkı ataması ve lisanslama konusunda biraz tartışma yaptık. Başlangıçta bunu yapmaktan rahatsız oldum, ancak Richard Stallman ve diğerlerinin bazı yorumları nedeniyle, telif hakkı ataması düşündüğüm kadar kısıtlayıcı olmayabilir. Dahası, çalışmalarımı telif hakkı atamasına alternatif olarak kamu malı yapmak benim için mümkün olabilir.

Her durumda, şimdiye kadar yamalar için Stefan teşekkürler! Umarım bu değişiklikleri geliştirmeye devam edersiniz, ancak değilse, sorun değil ve bir noktada geliştirmeye devam edebilirim. Ayrıca bu sorunun çözümüne içgörü ve katkı sunan herkese teşekkür ediyorum.

Yine başka bir güncelleme:

Vay be, bu özellik nihayet indi ve Emacs 27'de olacak gibi görünüyor . Stefan Monnier sayesinde!


Harika bir soru.
Drew

use-packagebunun için bir yol.
Dodgie

Sorunu küçümsemeye çalışmama (başlangıç ​​gecikmesi önemlidir!), Ancak emac'leri bir daemon / sunucu olarak çalıştırmayı düşünün, böylece sadece bir kez başlangıç ​​maliyeti ödersiniz.
GManNickG

1
@GManNickG Emacs'ı sunucu olarak çalıştırıyorum. Ne yazık ki, her zaman ve sonra Emacs'ı çok sert itiyorum veya çok fazla tamir ediyorum ve bir yeniden başlatma işleri temizlemenin en iyi yoludur. Bu meydana geldiğinde, başlangıç ​​zamanımın optimum olmasını seviyorum.
GDP2

Yanıtlar:


13

Package.el'deki tasarım seçeneklerinden biri, işleri basitleştirmeye çalışmaktı. Bunun bir kısmı, package-initializekurulu olan tüm paketleri arar, daha sonra bunların hangilerinin etkinleştirilmesi gerektiğini anlamaya çalışır (sabitlemeye ve aynı paketin birden fazla sürümünün mevcut olması durumunda sürümlerin yeniliğine göre), ardından yükler her biri paketin <pkg>-autoloads.eldosyasını etkinleştirir .

Yani N yüklü paketler için, bu temelde N <pkg>-pkg.elpaket açıklama dosyalarını ve N <pkg>-autoloads.eldosyalarını okumak anlamına gelir . Büyük N'ler için bu ciddi bir sorun haline gelebilir. Başka bir potansiyel performans sorunu, N öğelerini ekleyeceğidir load-path, bu nedenle loadEmacs her N dizininde arama yapacağından her loadbiri yavaşlar.

Bunu denemenin ve hızlandırmanın çeşitli yolları vardır:

  • ~/.emacs.d/elpa/package-initialize.el(c)Tüm hakları <pkg>-autoloads.eldoğru sırayla birleştirmenin bir sonucu olacak bir dosyayı önceden hesaplamak için bir yol sağlayın . Daha sonra package-initialize, bu dosyayı mevcut olduğunda yükleyebilir ve diğer her şeyi atlayabilirsiniz. Daha sonra package-initialize.el(c)paketler eklendiğinde / güncellendiğinde / kaldırıldığında ya da kendinizin package-pinned-packagesveya dosyanızı değiştirdiğinizde dosyayı yenilemek / temizlemek için bir yol gerekir package-load-list. Bunun sistemde oldukça az değişiklikle yapılabileceğini düşünüyorum (gerçekten değişmesi gereken tek şey bence package-initializemevcut paketler hakkındaki meta verileri yüklemeden "sadece aktif hale getirmesi" söylenebilir).

  • Süper paketler oluşturmak / işlemek için bir yol sağlayın, yani birkaç paketi tek bir pakette birleştiren paket (böylece yalnızca bir eleman eklenir load-path, bir <pkg>-pkg.elve bir <pkg>-autoloads.elyüklü). Bunu yapmak daha zor olabilir (çünkü bu tür süper paketlerde bulunan paketlerin yalnızca bir bölümünü etkinleştiremezsiniz, bu nedenle bağımlılık / sürüm analizi zor olabilir).

Yukarıdaki ilk seçeneğin uygulanması oldukça kolay olmalı ve yüklü birçok paketiniz olduğunda package-initialize çok daha hızlı olacaktır . Bunu denemekle ilgileniyorsanız, benden yardım istemekten çekinmeyin.

FWIW, test kurulumumda böyle bir mega-autoloads dosyasını "elle" oluşturmaya çalıştım. Sonuçlar: package-initializeyaklaşık mega-autoloads.el0,9 saniye sürerken , dosyayı yüklemek 0,3 saniye alır, bu da nil'e bağlanarak 0,2 saniyeye ve dosyayı load-source-file-functionbayt derleyerek 0,1 saniyeye indirebilirim . Dürüst olmak gerekirse daha iyi hızlanmayı bekliyordum, ama yine de faydalı.

[EDIT] Bu "mega otomatik yükler" yaklaşımı artık Emacs'ın ana dalında (uzak bir gelecekte Emacs-27 olmak için) kullanılabilir. Yeni package-quickstartdeğişken tarafından kontrol edilir .


Bunlar çok ilginç fikirler. İlki daha çok yeryüzüne ve daha az meydan okumaya benziyor. İkincisi oldukça ilginç, ama bu package.elgeliştiriciler için bir iş gibi geliyor . Bu ilk seçenekten başlamak için ne tür tavsiyeleriniz var? Onunla neyi çekiçleyebileceğimi görmek istiyorum, çünkü çok daha uygulanabilir görünüyor.
GSYİH2

el-get tek otomatik yükler dosya yaklaşımını kullanır, temelde çoğu zaman çalışır. Otomatik yükleri değerlendirildikleri dosya sistemindeki konuma bağlı olan bazı paketlerde sorun var. "Doğru sırada" ile ne demek istediğinizi takip etmiyorum, neden otomatik yükleme yükleme sırası önemli değil ( mevcut paket için bile deterministik olduğunu düşünüyorum. el)?
npostavs

@ Stefante mümkünse çözümü burada paylaşın.
Manuel Uberti

1
@npostavs: Çoğu <pkg>-autoloads.eldosya yalnızca otomatik yüklemeleri ayarlar ve gerçekten sipariş vermeyi umursamaz, ancak rastgele başka şeyler yapmalarını engelleyen hiçbir şey yoktur ve package.el, <pkg>bağımlı olan paketin <pkg>kendisinden önce etkinleştirileceğini garanti etmez .
Stefan

1
Bu konuda bir diğer güncelleme: posta listesinde yeni bir konu başladım burada ve herkes Stefan'ın değişikliklerle dışarı veya test yorum yapmak serbesttir.
GDP2

6

package-initializeYüklemek için çok fazla zaman ayırmakla ilgili tanımladığınız sorun iyi bilinen bir sorundur. Ayrıca, bazı emacs çerçevelerinin otomatik yükleri manuel olarak yükleyerek çözmeye çalıştığı sorunlardan biridir.

Sorununuza iki çözüm görüyorum.

  1. İlgilendiğiniz paketlerin yollarını ayarlama ve otomatik yüklerini yükleme işlevlerini yazın (veya bir çerçeveden çıkarın).
  2. Hızı açıkça hedefleyen bir çerçeve kullanın. Şahsen DOOM emacs öneririm . Bu çerçevede, yaklaşık 1 saniyede 200'den fazla paket yüklüyorum.

DOOM emacs'ı tavsiye etmenin ana yanlarından biri, çerçevenin paket yönetimini emac'ların dışına çıkarmasıdır. Beni yanlış anlamayın, hala emacs paket yönetimi yapıyor, sadece paketleri yönetmek standart bir kullanıcı oturumu dışında yapılır. Buradaki felsefe: normalde emacs'ı başlatırken, tüm paketlerin mevcut olduğunu ve zaten yüklenebileceğini varsayabiliriz. Bu çok zaman kazandırır. DOOM emacs, emac'lara eşdeğer apt-getveya eşdeğer tür sağlar pacman. Bir paket kurulduktan sonra, emacs başladığında zaten kurulu olduğu varsayılır; soru sormadı.


Vay be, bu sorunun sadece beni etkilemediğini bilmekten memnunum. Beni DOOM Emacs'a yönlendirdiğiniz için teşekkür ederim. Daha yakından bakmam ve kendi kurulumuma neyin uyum sağlayabileceğimi görmem gerekecek.
GSYİH2

Bir süredir DOOM emacs ile oynuyorum (ve yapabildiğimde katkıda bulunuyorum). Eğer sorun yaşıyorsanız, benimle temas kurmaktan çekinmeyin.
UndeadKernel
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.