Le programme Go est trop volumineux. Pouvons-nous utiliser une initialisation paresseuse ?

Au fur et à mesure que l'entreprise se développe, la plupart d'entre elles sont de grandes unités au début, et la transformation est lente. Un entrepôt sera utilisé pendant plus de dix ans, et l'échelle de l'entrepôt est fondamentalement un processus. d’augmentation continue.

L'un des impacts est que la taille de l'application packagée devient de plus en plus grande, et je ne sais pas où elle est utilisée... La proposition à discuter aujourd'hui "proposition : langage : lazy init importe éventuellement importer sans effets secondaires ^[1]" est lié à cela.

Proposition

Contexte

Observons un code Go très simple et étudions-le. Le code suivant :

package main

import _ "crypto/x509"

func main() {}

Ce programme Go ne comporte que 3 lignes de code et ne ressemble à rien. Est-ce réellement le cas ?

Nous pouvons exécuter la commande suivante pour voir le processus d'initialisation :

$ go build --ldflags=--dumpdep main.go 2>&1 | grep inittask

Résultat de sortie :

runtime.main -> runtime..inittask
runtime.main -> main..inittask
main..inittask -> crypto/x509..inittask
crypto/x509..inittask -> bytes..inittask
crypto/x509..inittask -> crypto/sha256..inittask
crypto/x509..inittask -> encoding/pem..inittask
crypto/x509..inittask -> errors..inittask
crypto/x509..inittask -> sync..inittask
crypto/x509..inittask -> crypto/aes..inittask
crypto/x509..inittask -> crypto/cipher..inittask
crypto/x509..inittask -> crypto/des..inittask
...
context..inittask -> context.init.0
vendor/golang.org/x/net/dns/dnsmessage..inittask -> vendor/golang.org/x/net/dns/dnsmessage.init
vendor/golang.org/x/net/route..inittask -> vendor/golang.org/x/net/route.init
vendor/golang.org/x/net/route..inittask -> vendor/golang.org/x/net/route.init.0
...

Ce programme initialise en fait de nombreux progiciels (bibliothèques standards, packages tiers, etc.). Cela modifie la taille du package de 1,3 Mo standard à 2,3 Mo.

À une certaine échelle, tout le monde croit que cet impact coûte très cher. Parce que vous voyez que le programme Go 3 lignes ne fait rien de substantiel.

Les programmes sensibles aux performances de démarrage seront plus inconfortables. Les programmes ordinaires entreront également dans un cercle vicieux au fil du temps et le démarrage sera plus lent que la normale.

Solution

Nous examinerons la solution avec une autre proposition "proposition : spécification : Go 2 : autoriser le contrôle manuel sur l'initialisation des packages importés^[2]".

L'idée principale est d'introduire l'initialisation paresseuse (lazy init), qui est aussi souvent appelée chargement paresseux dans l'industrie. C'est-à-dire que l'importation réelle est effectuée lorsque cela est nécessaire et que l'initialisation est terminée lorsque le package n'est pas introduit.

Direction de l'optimisation : ajout principalement de déclarations d'initialisation paresseuses après l'importation du chemin du package, telles que les annotations go:lazyinit ou go:deferred mentionnées ci-dessous. Attendez que le programme soit réellement utilisé avant de l'initialiser formellement.

1、go:lazyinit 的例子：

package main

import (
      "crypto/x509" // go:lazyinit
      "fmt"
)

func main() {...}

2、go:deferred 的例子：

package main

import (
    _ "github.com/eddycjy/core" // go:deferred
    _ "github.com/eddycjy/util" // go:deferred
)

func main() {
    if os.Args[1] != "util" {
        // 现在要使用这个包，开始初始化
        core, err := runtime.InitDeferredImport("github.com/some/module/core")
        ...
    }
    ...
}

以此来实现，可以大大提高启动性能。

讨论

实际上在大多数的社区讨论中，对这个提案是又爱又恨。因为它似乎又有合理的诉求，但细思似乎又会发现完全不对劲。

这个提案的背景和解决方案，是治标不治本的。因为根本原因是：许多库滥用了 init 函数，让许多不必要的东西都初始化了。

Go 核心开发团队认为让库作者去修复这些库，而不是让 Go 来 “解决” 这些问题。如果支持惰性初始化，也会为这些低质量库的作者提供继续这样做的借口。

似曾相识的感觉

在写这篇文章时，我想起了 Go 的依赖管理（Go modules），其有一个设计是基于语义化版本的规范。

如下图

版本格式为 “主版本号.次版本号.修订号”，版本号的递增规则如下：

• 主版本号：当你做了不兼容的 API 修改。
• 次版本号：当你做了向下兼容的功能性新增。
• 修订号：当你做了向下兼容的问题修正。

Go modules 的原意是软件库都遵守这个规范，因此内部会有最小版本选择的逻辑。

也就是一个模块往往依赖着许多其它许许多多的模块，并且不同的模块在依赖时很有可能会出现依赖同一个模块的不同版本，Go 会把版本清单都整理出来，最终得到一个构建清单。

如下图：

Vous constaterez que la version finale des dépendances construite est susceptible d'être incohérente avec celle attendue, ce qui entraînera de nombreux problèmes commerciaux. Le plus classique est le problème de compatibilité multi-versions de grpc-go, protoc-go, etcd, qui fait souffrir de nombreuses personnes.

La conception de l'équipe Go dans ce domaine est relativement idéale, et Cao Da l'a également classée comme l'un des sept péchés capitaux des modules Go. La fonction init du progiciel présente de nombreux problèmes d'initialisation aléatoire, ce qui est également un peu familier.

Résumé

La solution (proposition) à ce problème est toujours en discussion. Évidemment, l'équipe Go espère que les auteurs de la bibliothèque logicielle pourront contraindre leur propre code et ne pas s'initialiser de manière aléatoire.

Que diriez-vous d'introduire l'initialisation paresseuse, qu'en pensez-vous ? Bienvenue pour laisser des messages et discuter dans la zone de commentaires.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!