Construire un Emacs 25 minimal pour les tests unitaires

Je voudrais construire une variante très minimale du tronc Emacs pour tester à l'unité mon package Emacs Lisp. La construction n'a besoin d'aucune interface graphique, d'aucune prise en charge d'image, etc. Elle devrait essentiellement être simplement un interpréteur Emacs Lisp minimal avec les bibliothèques Emacs Lisp de base, et elle devrait être rapide , idéalement en moins de cinq minutes.

Actuellement, je passe --with-x-toolkit=no --without-x --without-allà ./configure. Une fois terminé, il me dit que toutes les fonctionnalités d'Emacs sont désactivées, mais malheureusement, la construction prend encore près de dix minutes .

Je comprends qu'il pourrait être impossible d'obtenir la construction d'Emacs plus rapidement, mais ce qui me fait me demander, c'est qu'avec les mêmes drapeaux, Emacs 24.5 se construit en seulement deux minutes environ .

Quelle est la raison de cette différence flagrante, et puis-je obtenir le tronc Emacs pour construire aussi vite que Emacs 24.5?

Et, dans une question connexe, comment puis-je obtenir Emacs pour construire tranquillement? Actuellement, près de 80% de ma sortie de test unitaire est le bâtiment Emacs. Idéalement, je souhaiterais make installne pas imprimer du tout de sortie.

La raison pour laquelle 24.5 se construit si rapidement pour vous est que les .elcfichiers sont réellement distribués dans l'archive tar, voir make-dist . Lors de la construction à partir de git, la majorité du temps est consacrée à la compilation des .elfichiers .elc. En optimisant le code C, la compilation Lisp peut aller plus vite, mais cela prend encore beaucoup de temps. Comparez les temps de construction en utilisant vos paramètres d'origine (~ 14 vs ~ 1 minutes) avec une construction en utilisantCFLAGS='-O2 -march=native' (~ 9 vs ~ 1,5 minutes).

De plus, le clonage depuis git prend environ une minute, tandis que le téléchargement et le déballage de l'archive tar prennent environ 5 secondes. Comparez les temps de construction entre les versions lors du téléchargement de l'archive git à partir de github (~ 5, ~ 6, ~ 8 minutes respectivement pour v24.5, master et emacs-25. Comme vous pouvez le voir, lorsque vous n'utilisez pas l'archive de distribution, tous les les temps de construction sont au moins du même ordre de grandeur (vous ne savez pas pourquoi emacs-25 était plus lent que master, pourrait être une variation aléatoire, ou du code obsolète a été supprimé dans master?).

Et, dans une question connexe, comment puis-je obtenir Emacs pour construire tranquillement? Actuellement, près de 80% de ma sortie de test unitaire est le bâtiment Emacs. Idéalement, je souhaiterais make installne pas imprimer du tout de sortie.

Vous pouvez toujours rediriger la sortie vers /dev/null. Pour mes expériences, j'ai canalisé la make installsortie pour grep -E '^(make|[A-Z])'réduire la sortie (le javascript Travis CI qui formate le journal sur le Web avait des problèmes avec la sortie complète).

puis-je obtenir le tronc Emacs pour construire aussi vite que Emacs 24.5?

Non (ou oui dans le sens où vous pouvez obtenir Emacs 24.5 pour construire (presque) aussi lentement que le tronc Emacs: p). Mais ce que vous pouvez faire, c'est d'enregistrer la version Emacs, et il suffit de télécharger ce résultat mis en cache pour les tests unitaires. J'ai implémenté cela dans la branche de téléchargement de ma fourche emacs-travis, voici un exemple d'utilisation par yasnippet : Le temps d'installation d'Emacs est de ~ 2,5 secondes.

Voici différentes suggestions.

1. Aucun fichier elc.

Comme indiqué ci-dessous, la compilation de tous les fichiers lisp représente au moins 10% du temps. Une façon de désactiver cela est de modifier la cible loaddefs dans le fichier lisp/Makefileet de la changer en:

    $(lisp)/loaddefs.el: $(LOADDEFS)
          true

2. Aucune optimisation du compilateur ou tables de symboles de débogueur

Actuellement, je passe --with-x-toolkit = no --without-x --without-all à ./configure.

J'ai pu réduire le temps de compilation C à 1/4 du temps (d'un peu moins d'une minute à 16 secondes) dans le src en changeant simplement les drapeaux de compilation par défaut. La valeur par défaut CFLAGS Je me suis eu: -g -O3.

Utilisez donc à la place CFLAGS=''.

3. Ne lancez pas make install, mais exécutez simplement les emacs construits depuis l'intérieur du répertoire src .

Comme indiqué ci-dessous, 10% du temps est consacré à la création de documents. Bien que je ne l'ai pas chronométré, il y a sans aucun doute beaucoup de temps à copier et à compresser des fichiers elisp make install. Alors ne le fais pas. Si vous souhaitez refaire les chronogrammes, exécutez remake --profile.

Les observations ci-dessus sont basées sur ci-dessous ....

La première étape consiste à comprendre où le temps est passé pour trouver comment le réduire. Heureusement pour quelque chose comme Emacs, j'ai récemment écrit (ou plutôt étendu) un outil pour vous aider à le découvrir. J'ai ajouté une --profileoption pour refaire (un fork de GNU make) qui vous dira combien de temps est consacré à des cibles spécifiques.

J'ai essayé de créer un instantané récent et oui, cela prend environ 10 minutes. Si vous n'avez pas installé de remake, j'ai un résumé des informations de profilage que vous pouvez utiliser pour ma course. J'utilise kcachegrind pour afficher les informations mais il peut y avoir d'autres outils pour les outils de visualisation. Il y a un png dans l'essentiel qui est une capture d'écran de la course.

Passons maintenant aux détails ...

Dans ma course, environ 20% du temps est consacré à la création de fichiers lisp et info que vous n'avez pas vraiment besoin de faire. En fait, un peu plus est dépensé dans les fichiers lisp que dans les fichiers info. Vous pouvez probablement modifier le Makefile pour ignorer cela.

Il pourrait être intéressant de comparer avec emacs 24. Je suppose que la taille des deux a augmenté proportionnellement.

S'il y a un intérêt (que vous pouvez montrer par des votes positifs), je proposerai des hacks spécifiques au Makefile. Cependant, cela en soi devrait être suffisant pour une personne motivée à travailler.