Comment Emacs parvient-il à démarrer instantanément avec de nombreux fichiers électroniques?


11

Comme tous les Emacs le savent, je souffre actuellement de ma configuration point-Emacs étendue. Tous mes packages se trouvent dans les conteneurs de use-package, et j'ai bytecompilé tous mes .elfichiers. Même avec cela, Emacs démarre en 6,4 secondes, puis charge le reste des packages (environ 40 d'entre eux) par la suite.

Je réfléchissais à une autre façon de résoudre le long temps de démarrage, puis j'ai remarqué quelque chose. L'Emacs par défaut (sans configuration utilisateur) utilise de nombreuses .elbibliothèques, qui sont incluses avec chaque Emacs. Ils sont situés à \shares\emacs\version number\lisp\.

Même avec de nombreux fichiers lisp, il parvient à démarrer en une seconde. Lorsque j'inspectais les fichiers de nombreux packages inclus avec les Emacs par défaut, je n'ai rien trouvé d'extraordinaire qui pourrait expliquer pourquoi Emacs parvient à démarrer en une seconde. Quelqu'un pourrait-il me dire comment Emacs gère cela, même avec des milliers de .elfichiers?


1
Utilisez-vous autant que possible :defer tdans vos use-packagedéclarations?
lunaryorn du

7
De nombreuses bibliothèques de base dans Emacs sont préchargées dans l'exécutable, via le mécanisme de vidage utilisé lors de la construction d'Emacs, ce qui donne également l'illusion qu'il charge beaucoup de choses incroyablement rapidement. Voyez C-h i g (elisp) Building Emacssi vous souhaitez en savoir plus.
phils

2
@phils: Ce serait bien si vous pouviez étendre votre commentaire à une réponse, il semble que le mécanisme de vidage ne soit pas encore mentionné sur Emacs-SE.
paprika

et le mien a 76 ans ..
Leu_Grady

paprika: Fait ..
phils

Réponses:


9

Quelqu'un pourrait-il me dire comment Emacs gère cela, même avec des milliers de fichiers .el?

Emacs «gère» cela en ne se chargeant pas au démarrage, ce qui ne retarde pas le chargement de l'application principale. Ceci à son tour comme effet de rendre plus rapidement le contrôle du clavier à l'utilisateur.

Mais quand est-il chargé? Lors de la première utilisation de cette fonction, de ce mode ou de cette fonctionnalité.

Ça ne ralentit pas? Oui, lors de la première utilisation. Voilà le compromis. Souhaitez-vous ralentir au démarrage d'emacs ou lors de la première utilisation.

Est-ce visible? Le chargement au démarrage semble prendre plus de temps car d'autres bibliothèques de base sont également chargées. Mais à la première utilisation, il semble plus rapide car seule cette fonction de sous-ensemble est chargée.

Alors pourquoi quelqu'un choisirait-il la charge au démarrage? Parce que certains ne craignent pas d'attendre pour charger toutes les bibliothèques fréquemment utilisées au démarrage, une fois chargées, toutes les opérations s'exécutent par la suite.

Comment choisir? Comme Drew et d'autres l'ont souligné dans leurs réponses à cette même question, vous pouvez utiliser le chargement automatique et des astuces similaires pour contrôler. Mais la considération la plus importante devrait être votre modèle d'utilisation. Si vous utilisez des emacs comme vi, en ouvrant et en fermant constamment, le temps de démarrage devient douloureusement évident. Mais d'un autre côté, si vous utilisez emacs tout le temps, le temps de démarrage de 1 seconde ou 1 minute ne sera pas aussi visible ou suffisamment important pour s'en soucier.

Notez que vous pouvez utiliser le mode batch ou Zile pour un démarrage instantané pendant le test, l'exécution ou autrement en utilisant emacs comme vi.

Ma préférence est de charger au démarrage afin que toutes les erreurs soient détectées dès le départ. Je préfère ne pas avoir à faire face à des erreurs de chargement au milieu d'une journée de travail lorsque j'ai d'innombrables tampons, modes et états de compilation actifs ainsi que plusieurs emplacements distants gérés par TRAMP. Le débogage des erreurs de chargement automatique dans de telles conditions n'est pas très agréable.


10

La plupart des bibliothèques incluses ne sont pas chargées au démarrage.

Certaines commandes, etc. sont chargées automatiquement , ce qui signifie qu'Emacs les reconnaît et sait comment les charger. Lorsque vous essayez d'utiliser une commande qui est chargée automatiquement, Emacs charge ensuite la bibliothèque qui la définit, si elle n'a pas encore été chargée.

Vous pouvez créer vos propres chargements automatiques, que ce soit pour vos propres commandes ou des commandes dans des bibliothèques que vous n'avez pas écrites. Voir le manuel Elisp, nœud Autoload .


Aussi connu que le chargement paresseux, je présume? Existe-t-il un exemple de la façon dont le chargement différé est réalisé, qui ne sera chargé que lors de son appel?
ReneFroger

Je ne sais pas ce que vous demandez. Oui, vous pourriez l'appeler chargement paresseux. Il y a des exemples et des explications dans le manuel Elisp. L'ajout d'un cookie de chargement automatique ( ;;;###autoload) juste avant une définition de commande dans votre bibliothèque est un moyen de lui donner une définition de chargement automatique, garantissant que sa bibliothèque sera chargée lorsque quelqu'un l'invoquera.
Drew

... mais lisez ce lien manuel pour comprendre comment / si ces cookies de chargement automatique sont traités. Le gestionnaire de packages les gère pour tous les packages ELPA. Sinon, vous appelez (autoload...)directement dans votre fichier init pour les enregistrer.
phils

Merci pour vos deux réponses, cela a beaucoup aidé à en savoir plus!
ReneFroger

9

En plus des autres réponses (qui expliquent comment la majorité des bibliothèques ne sont en fait chargées qu'à la demande), il y a aussi la question du préchargement de nombreuses bibliothèques elisp de base dans l' emacsexécutable lui-même, ce qui en donne l'illusion de charger un beaucoup de choses incroyablement rapidement.

Ceci est réalisé en exécutant une version dite «nue» d'Emacs (qui est ce qui a été réellement compilé et qui est entièrement fonctionnel, mais ne contient que l'interpréteur elisp et d'autres fonctionnalités de base écrites en C), et en disant que charger toutes les bibliothèques elisp qui devraient être préchargées, avant de finalement "vider" le emacsbinaire réel avec ces bibliothèques intégrées.

Ce mécanisme est détaillé dans le manuel elisp:
C-hig (elisp) Building Emacs RET

Si vous avez compilé Emacs vous-même, vous pouvez expérimenter ce processus et même vider des versions alternatives de l'exécutable final si vous le souhaitez (ce n'est généralement pas recommandé, mais l'installation est là).

Le temacsbinaire compilé se trouve dans le srcrépertoire, et vous pouvez comparer la différence dans les heures de démarrage en exécutant chaque version comme suit:

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

Sur mon système, la première prend ~ 4 secondes (pendant lesquelles 111 bibliothèques elisp sont chargées), tandis que la seconde prend ~ 0,02 seconde.


Très sympa @phils pour avoir fait valoir ce point.
Emacs User
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.