¿Cómo reducir el tamaño del archivo compilado?

Comparemos cy vayamos: Hello_world.c:

#include<stdio.h>
int main(){
    printf("Hello world!");
}

Hello_world.go:

package main
import "fmt"
func main(){
    fmt.Printf("Hello world!")
}

Compila ambos:

$gcc Hello_world.c -o Hello_c 
$8g Hello_world.go -o Hello_go.8
$8l Hello_go.8 -o Hello_go

¿Y qué es eso?

$ls -ls
... 5,4K 2010-10-05 11:09 Hello_c
... 991K 2010-10-05 11:17 Hello_go

Aproximadamente 1Mb Hola mundo. ¿Me estás tomando el pelo? ¿Qué hice mal?

(tira Hello_go -> 893K solamente)

¿Es un problema que el archivo sea más grande? No sé Go, pero supongo que enlaza estáticamente alguna biblioteca en tiempo de ejecución, lo que no es el caso del programa C. Pero probablemente eso no sea nada de qué preocuparse tan pronto como su programa crezca.

Como se describe aquí , la vinculación estática del tiempo de ejecución de Go es la opción predeterminada. Esa página también le indica cómo configurar los enlaces dinámicos.

Si está utilizando un sistema basado en Unix (por ejemplo, Linux o Mac OSX), puede intentar eliminar la información de depuración incluida en el ejecutable compilándolo con el indicador -w:

go build -ldflags "-w" prog.go

Los tamaños de archivo se reducen drásticamente.

Para obtener más detalles, visite la página del BGF: http://golang.org/doc/gdb

La respuesta de 2016:

1. Utilice Go 1.7

2. Compilar con go build -ldflags "-s -w"

➜ ls -lh hello
-rwxr-xr-x 1 oneofone oneofone 976K May 26 20:49 hello*

3. Luego use upx, goupxya no es necesario desde 1.6.

➜ ls -lh hello
-rwxr-xr-x 1 oneofone oneofone 367K May 26 20:49 hello*

Los binarios de Go son grandes porque están vinculados estáticamente (a excepción de los enlaces de biblioteca que utilizan cgo). Intente vincular estáticamente un programa en C y verá que crece a un tamaño comparable.

Si esto es realmente un problema para usted (que me cuesta creer), puede compilar con gccgo y vincular dinámicamente.

Debería obtener goupx , "arreglará" los ejecutables de Golang ELF para trabajar upx. Ya tengo una reducción del tamaño de archivo de alrededor del 78% en algunos casos ~16MB >> ~3MB.

La relación de compresión suele ser del 25%, por lo que vale la pena intentarlo:

$ go get github.com/pwaller/goupx
$ go build -o filename
$ goupx filename

>>

2014/12/25 10:10:54 File fixed!

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  16271132 ->   3647116   22.41%  linux/ElfAMD   filename                            

Packed 1 file.

EXTRA: la -sbandera (tira) puede encoger aún más el archivo bingoupx -s filename

cree un archivo llamado main.go, intentemos con un programa simple de hola mundo.

package main

import "fmt"

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

Yo uso go versión 1.9.1

$ go version
 go version go1.9.1 linux/amd64

Compile con go buildcomando estándar .

$ go build main.go
$ ls -lh
-rwxr-xr-x-x 1 nil nil 1.8M Oct 27 07:47 main

Compilemos una vez más con go buildpero con ldflagscomo se sugirió anteriormente,

$ go build -ldflags "-s -w" main.go
$ ls -lh
-rwxr-xr-x-x 1 nil nil 1.2M Oct 27 08:15 main

El tamaño del archivo se reduce en un 30%.

Ahora, usemos gccgo,

$ go version
 go version go1.8.1 gccgo (GCC) 7.2.0 linux/amd64

La construcción de ir con gccgo,

$ go build main.go
$ ls -lh
-rwxr-xr-x 1 nil nil 34K Oct 27 12:18 main

El tamaño binario se reduce casi en un 100%. Intentemos una vez más construir nuestro main.gocon gccgopero con banderas de compilación,

$ go build -gccgoflags "-s -w" main.go
-rwxr-xr-x 1 nil nil 23K Oct 27 13:02 main

Advertencia: ya que los gccgobinarios se vincularon dinámicamente. Si tiene un binario que es muy grande en tamaño, su binario cuando se compila con gccgo no se reducirá en un 100%, pero se reducirá en tamaño en una cantidad considerable.

En comparación con gc, gccgo es más lento para compilar código pero admite optimizaciones más potentes, por lo que un programa vinculado a la CPU creado por gccgo generalmente se ejecutará más rápido. Todas las optimizaciones implementadas en GCC a lo largo de los años están disponibles, incluida la inserción, las optimizaciones de bucle, la vectorización, la programación de instrucciones y más. Si bien no siempre produce un mejor código, en algunos casos los programas compilados con gccgo pueden ejecutarse un 30% más rápido.

Se espera que las versiones de GCC 7 incluyan una implementación completa de las bibliotecas de usuario de Go 1.8. Al igual que con versiones anteriores, el tiempo de ejecución de Go 1.8 no está completamente combinado, pero eso no debería ser visible para los programas de Go.

Pros:

1. Tamaño reducido
2. Optimizado.

Contras

1. Lento
2. No se puede utilizar la última versión de go.

Puedes ver aquí y aquí .

Ejemplo de hello-world más compacto:

package main

func main() {
  print("Hello world!")
}

Somos grandes fmtpaquetes esquiados y binarios notablemente reducidos:

  $ go build hello.go
  $ ls -lh hello
  ... 259K ... hello2
  $ strip hello
  $ ls -lh hello
  ... 162K ... hello2

No tan compacto como C, pero aunque medido en K, no en M :) Ok, no es una forma general, solo muestra algunas formas de optimizar un tamaño: use strip e intente usar paquetes mínimos. De todos modos, Go no es un lenguaje para hacer binarios de tamaño pequeño.

2018 respuesta para la próxima Go 1.11, como tuiteó por Brad Fitzpatrick (mediados de junio de 2018):

Hace unos minutos, las secciones DWARF en los binarios #golang ELF ahora están comprimidas, por lo que en tip los binarios ahora son más pequeños que Go 1.10, incluso con todas las cosas de depuración adicionales en tip.

Cf. Problema de Golang 11799 :

Comprimir nuestra información de depuración puede ofrecer una ganancia significativa y barata de tamaño de archivo.

Ver más en el compromiso 594eae5

cmd / link: comprime secciones DWARF en binarios ELF

La parte más complicada de esto es que el código de diseño binario (blk, elfshbits y varias otras cosas) asume un desplazamiento constante entre las ubicaciones de los archivos de símbolos y secciones y sus direcciones virtuales.

La compresión, por supuesto, rompe este desplazamiento constante.
Pero necesitamos asignar direcciones virtuales a todo antes de la compresión para resolver las reubicaciones antes de la compresión.

Como resultado, la compresión necesita volver a calcular la "dirección" de las secciones y símbolos DWARF en función de su tamaño comprimido.
Afortunadamente, estos están al final del archivo, por lo que esto no perturba ninguna otra sección o símbolo. (Y hay, por supuesto, una sorprendente cantidad de código que asume que el segmento DWARF es el último, así que, ¿cuál es un lugar más?)

name        old exe-bytes   new exe-bytes   delta
HelloSize      1.60MB ± 0%     1.05MB ± 0%  -34.39%  (p=0.000 n=30+30)
CmdGoSize      16.5MB ± 0%     11.3MB ± 0%  -31.76%  (p=0.000 n=30+30)
[Geo mean]     5.14MB          3.44MB       -33.08%

Rob Pike menciona :

Eso solo ayuda en máquinas que usan ELF.
Los binarios todavía son demasiado grandes y están creciendo.

Brad respondió:

Al menos es algo. Estaba a punto de ser mucho peor.
Detuvo el sangrado para una liberación.

Motivos : depure la información, pero también registre el mapa para que el GC permita que cualquier instrucción sea un punto de guardado.

El binario contiene de forma predeterminada el recolector de basura, el sistema de programación que administra las rutinas de marcha y todas las bibliotecas que importa.

El resultado es un tamaño mínimo de aproximadamente 1 Mb.

Desde Go 1.8 también puede usar el nuevo sistema de complementos para dividir su binario en algo que se parezca a bibliotecas compartidas. Para esta versión, solo funciona en Linux, pero probablemente se admitirán otras plataformas en el futuro.

https://tip.golang.org/pkg/plugin/

Puede echar un vistazo a mi pequeña investigación sobre este tema: https://github.com/xaionaro/documentation/blob/master/golang/reduce-binary-size.md

Muestra paso a paso cómo reducir una muestra binaria estática hello-world de 2MiB a 15KiB estática-binaria o a 10KiB dinámica-binaria. Por supuesto que existen muchas limitaciones.

Por defecto, gcc enlaza dinámicamente y va - estáticamente.

Pero si enlaza su código C de forma estática, puede obtener un binario con un tamaño mayor.

En mi caso:

• go x64 (1.10.3) - binario generado con un tamaño de 1214208 bytes
• gcc x64 (6.2.0) - binario generado con tamaño 1421312 byte

ambos binarios están vinculados estáticamente y sin debug_info.

go build -ldflags="-s -w" -o test-go test.go
gcc -static -s -o test-c test.c