Raison de la taille énorme de l'exécutable compilé de Go

J'ai respecté un programme hello world Go qui a généré un exécutable natif sur ma machine Linux. Mais j'ai été surpris de voir la taille du simple programme Hello world Go, il était de 1,9 Mo!

Pourquoi l'exécutable d'un programme aussi simple dans Go est-il si énorme?

Cette question exacte apparaît dans la FAQ officielle: Pourquoi mon programme trivial est-il un si gros binaire?

Citant la réponse:

Les lieurs dans la chaîne d'outils de gc ( 5l, 6l, et 8l) font la liaison statique. Tous les fichiers binaires Go incluent donc l'environnement d'exécution Go, ainsi que les informations de type d'exécution nécessaires pour prendre en charge les vérifications de type dynamiques, la réflexion et même les traces de pile de panique.

Un simple programme C "hello, world" compilé et lié statiquement à l'aide de gcc sous Linux fait environ 750 Ko, y compris une implémentation de printf. Un programme Go équivalent utilise fmt.Printfenviron 1,9 Mo, mais cela inclut un support d'exécution plus puissant et des informations de type.

Ainsi, l'exécutable natif de votre Hello World fait 1,9 Mo car il contient un runtime qui fournit le ramasse-miettes, la réflexion et de nombreuses autres fonctionnalités (que votre programme n'utilise peut-être pas vraiment, mais il est là). Et l'implémentation du fmtpackage que vous avez utilisé pour imprimer le "Hello World"texte (plus ses dépendances).

Maintenant, essayez ce qui suit: ajoutez une autre fmt.Println("Hello World! Again")ligne à votre programme et compilez-la à nouveau. Le résultat ne sera pas 2x 1,9 Mo, mais toujours seulement 1,9 Mo! Oui, car toutes les bibliothèques utilisées ( fmtet ses dépendances) et le runtime sont déjà ajoutés à l'exécutable (et donc juste quelques octets supplémentaires seront ajoutés pour imprimer le 2ème texte que vous venez d'ajouter).

Considérez le programme suivant:

package main

import "fmt"

func main() {
    fmt.Println("Hello World!")
}

Si je construis ceci sur ma machine Linux AMD64 (Go 1.9), comme ceci:

$ go build
$ ls -la helloworld
-rwxr-xr-x 1 janf group 2029206 Sep 11 16:58 helloworld

J'obtiens un binaire d'environ 2 Mo de taille.

La raison à cela (qui a été expliquée dans d'autres réponses) est que nous utilisons le package "fmt" qui est assez volumineux, mais le binaire n'a pas non plus été supprimé et cela signifie que la table des symboles est toujours là. Si nous demandons au compilateur de supprimer le binaire, il deviendra beaucoup plus petit:

$ go build -ldflags "-s -w"
$ ls -la helloworld
-rwxr-xr-x 1 janf group 1323616 Sep 11 17:01 helloworld

Cependant, si nous réécrivons le programme pour utiliser la fonction intégrée print, au lieu de fmt.Println, comme ceci:

package main

func main() {
    print("Hello World!\n")
}

Et puis compilez-le:

$ go build -ldflags "-s -w"
$ ls -la helloworld
-rwxr-xr-x 1 janf group 714176 Sep 11 17:06 helloworld

Nous nous retrouvons avec un binaire encore plus petit. C'est aussi petit que nous pouvons l'obtenir sans recourir à des astuces comme UPX-packing, donc la surcharge du Go-runtime est d'environ 700 Ko.

Notez que le problème de taille binaire est suivi par le problème 6853 dans le projet golang / go .

Par exemple, commit a26c01a (pour Go 1.4) réduit hello world de 70 ko :

car nous n'écrivons pas ces noms dans la table des symboles.

Étant donné que le compilateur, l'assembleur, l'éditeur de liens et le runtime pour 1.5 seront entièrement dans Go, vous pouvez vous attendre à une optimisation supplémentaire.

Mise à jour 2016 Go 1.7: cela a été optimisé: voir " Smaller Go 1.7 binaires ".

Mais ces jours-ci (avril 2019), ce qui prend le plus de place est runtime.pclntab.
Voir « Pourquoi mes fichiers exécutables Go sont-ils si volumineux? Visualisation de la taille des exécutables Go à l'aide de D3 » de Raphael 'kena' Poss .

Ce n'est pas trop bien documenté, mais ce commentaire du code source de Go suggère son objectif:

// A LineTable is a data structure mapping program counters to line numbers.

Le but de cette structure de données est de permettre au système d'exécution Go de produire des traces de pile descriptives en cas de panne ou de requêtes internes via l' runtime.GetStackAPI.

Cela semble donc utile. Mais pourquoi est-il si grand?

L'URL https://golang.org/s/go12symtab cachée dans le fichier source lié ci-dessus redirige vers un document qui explique ce qui s'est passé entre Go 1.0 et 1.2. Paraphraser:

avant la version 1.2, l'éditeur de liens Go émettait une table de lignes compressée et le programme la décompressait lors de l'initialisation au moment de l'exécution.

dans Go 1.2, il a été décidé de pré-étendre la table de lignes du fichier exécutable dans son format final adapté à une utilisation directe au moment de l'exécution, sans étape de décompression supplémentaire.

En d'autres termes, l'équipe Go a décidé d'agrandir les fichiers exécutables pour gagner du temps lors de l'initialisation.

En outre, en regardant la structure des données, il semble que sa taille globale dans les binaires compilés est super-linéaire dans le nombre de fonctions dans le programme, en plus de la taille de chaque fonction.