Причина огромного размера скомпилированного исполняемого файла Go

Я выполнил программу Hello World Go, которая генерировала собственный исполняемый файл на моей Linux-машине. Но я был удивлен, увидев размер простой программы Hello world Go, он составлял 1,9 МБ!

Почему исполняемый файл такой простой программы на Go так велик?

Этот точный вопрос появляется в официальном FAQ: Почему моя простая программа имеет такой большой двоичный файл?

Цитируя ответ:

Линкеры в цепи дс инструмента ( 5l, 6lи 8l) делать статические ссылки. Поэтому все двоичные файлы Go включают среду выполнения Go вместе с информацией о типе времени выполнения, необходимой для поддержки динамических проверок типов, отражения и даже трассировки стека во время паники.

Простая программа C "hello, world", скомпилированная и скомпилированная статически с использованием gcc в Linux, занимает около 750 КБ, включая реализацию printf. Эквивалентная программа Go использует fmt.Printfоколо 1,9 МБ, но включает более мощную поддержку времени выполнения и информацию о типе.

Таким образом, размер собственного исполняемого файла Hello World составляет 1,9 МБ, потому что он содержит среду выполнения, которая обеспечивает сборку мусора, отражение и многие другие функции (которые ваша программа на самом деле может не использовать, но она есть). И реализация fmtпакета, который вы использовали для печати "Hello World"текста (плюс его зависимости).

Теперь попробуйте следующее: добавьте еще одну fmt.Println("Hello World! Again")строку в свою программу и снова скомпилируйте ее. В результате получится не 2x 1,9 МБ, а всего 1,9 МБ! Да, потому что все используемые библиотеки ( fmtи их зависимости) и среда выполнения уже добавлены в исполняемый файл (и поэтому будет добавлено еще несколько байтов для печати второго текста, который вы только что добавили).

Рассмотрим следующую программу:

package main

import "fmt"

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

Если я построю это на своей машине Linux AMD64 (Go 1.9), например:

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

Я получаю двоичный файл размером около 2 МБ.

Причина этого (которая была объяснена в других ответах) заключается в том, что мы используем довольно большой пакет «fmt», но двоичный файл также не был удален, и это означает, что таблица символов все еще существует. Если вместо этого мы укажем компилятору удалить двоичный файл, он станет намного меньше:

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

Однако, если мы перепишем программу, чтобы использовать встроенную функцию print вместо fmt.Println, например:

package main

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

А затем скомпилируйте его:

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

Мы получаем еще меньший двоичный файл. Это настолько мало, насколько мы можем получить, не прибегая к уловкам вроде UPX-упаковки, поэтому накладные расходы Go-runtime составляют примерно 700 Кбайт.

Обратите внимание, что проблема с размером двоичного файла отслеживается проблемой 6853 в проекте golang / go .

Например, команда commit a26c01a (для Go 1.4) сократила привет, мир на 70 КБ :

потому что мы не записываем эти имена в таблицу символов.

Учитывая, что компилятор, ассемблер, компоновщик и среда выполнения для 1.5 будут полностью на Go, вы можете ожидать дальнейшей оптимизации.

Обновление 2016 Go 1.7: это было оптимизировано: см. « Меньшие двоичные файлы Go 1.7 ».

Но в этот день (апрель 2019 года) больше всего места занимает runtime.pclntab.
См. « Почему мои исполняемые файлы Go такие большие? Визуализация размера исполняемых файлов Go с использованием D3 » от Рафаэля 'kena' Poss .

Это не слишком хорошо документировано, однако этот комментарий из исходного кода Go предполагает его цель:

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

Цель этой структуры данных - дать возможность исполняющей системе Go создавать описательные трассировки стека при сбое или при внутренних запросах через runtime.GetStackAPI.

Так что это кажется полезным. Но почему он такой большой?

URL-адрес https://golang.org/s/go12symtab, скрытый в указанном выше исходном файле, перенаправляет на документ, объясняющий, что произошло между Go 1.0 и 1.2. Перефразируя:

до 1.2 компоновщик Go выдавал сжатую таблицу строк, и программа распаковывала ее при инициализации во время выполнения.

в Go 1.2 было принято решение предварительно развернуть таблицу строк в исполняемом файле до ее окончательного формата, пригодного для непосредственного использования во время выполнения, без дополнительного шага распаковки.

Другими словами, команда Go решила увеличить размер исполняемых файлов, чтобы сэкономить время инициализации.

Кроме того, глядя на структуру данных, кажется, что ее общий размер в скомпилированных двоичных файлах суперлинейен по количеству функций в программе, помимо того, насколько велика каждая функция.