La solution de Paul fournit une solution simple et générale.
La question demande "le moyen le plus rapide et le plus simple" . Parlons le plus rapidement partie . Nous arriverons à notre code final le plus rapide de manière itérative. L'analyse comparative de chaque itération se trouve à la fin de la réponse.
Toutes les solutions et le code de référence peuvent être trouvés sur le Go Playground . Le code sur le Playground est un fichier de test, pas un exécutable. Vous devez l'enregistrer dans un fichier nommé XX_test.goet l'exécuter avec
go test -bench . -benchmem
Avant - propos :
La solution la plus rapide n'est pas une solution idéale si vous avez juste besoin d'une chaîne aléatoire. Pour cela, la solution de Paul est parfaite. C'est si les performances comptent. Bien que les 2 premières étapes ( octets et reste ) puissent être un compromis acceptable: elles améliorent les performances de 50% (voir les chiffres exacts dans la section II. Benchmark ) et n'augmentent pas la complexité de manière significative.
Cela dit, même si vous n'avez pas besoin de la solution la plus rapide, la lecture de cette réponse peut être aventureuse et éducative.
I. Améliorations
1. Genesis (Runes)
Pour rappel, la solution générale originale que nous améliorons est la suivante:
func init() {
rand.Seed(time.Now().UnixNano())
}
var letterRunes = []rune("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ")
func RandStringRunes(n int) string {
b := make([]rune, n)
for i := range b {
b[i] = letterRunes[rand.Intn(len(letterRunes))]
}
return string(b)
}
2. octets
Si les caractères à choisir et à assembler la chaîne aléatoire contiennent uniquement les lettres majuscules et minuscules de l'alphabet anglais, nous ne pouvons travailler avec des octets que parce que les lettres de l'alphabet anglais sont mappées aux octets 1 à 1 dans l'encodage UTF-8 (qui est la façon dont Go stocke les chaînes).
Donc au lieu de:
var letters = []rune("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ")
on peut utiliser:
var letters = []bytes("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ")
Ou encore mieux:
const letters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
Maintenant, c'est déjà une grande amélioration: nous pourrions y parvenir const(il y a des stringconstantes mais pas de constantes de tranche ). Comme gain supplémentaire, l'expression len(letters)sera également un const! (L'expression len(s)est constante si sest une constante chaîne.)
Et à quel prix? Rien du tout. strings peut être indexé qui indexe ses octets, parfait, exactement ce que nous voulons.
Notre prochaine destination ressemble à ceci:
const letterBytes = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
func RandStringBytes(n int) string {
b := make([]byte, n)
for i := range b {
b[i] = letterBytes[rand.Intn(len(letterBytes))]
}
return string(b)
}
3. Reste
Les solutions précédentes obtiennent un nombre aléatoire pour désigner une lettre aléatoire en appelant les rand.Intn()délégués Rand.Intn()auxquels les délégués àRand.Int31n() .
Ceci est beaucoup plus lent que celui rand.Int63()qui produit un nombre aléatoire avec 63 bits aléatoires.
Ainsi, nous pourrions simplement appeler rand.Int63()et utiliser le reste après la division par len(letterBytes):
func RandStringBytesRmndr(n int) string {
b := make([]byte, n)
for i := range b {
b[i] = letterBytes[rand.Int63() % int64(len(letterBytes))]
}
return string(b)
}
Cela fonctionne et est beaucoup plus rapide, l'inconvénient est que la probabilité de toutes les lettres ne sera pas exactement la même (en supposant que rand.Int63()tous les nombres de 63 bits soient identiques ). Bien que la distorsion soit extrêmement faible car le nombre de lettres 52est beaucoup plus petit que 1<<63 - 1, donc en pratique, c'est parfaitement bien.
Pour faciliter la compréhension: disons que vous voulez un nombre aléatoire dans la plage de 0..5. En utilisant 3 bits aléatoires, cela produirait les nombres 0..1avec une probabilité double par rapport à la plage 2..5. En utilisant 5 bits aléatoires, les nombres dans la plage 0..1se produiraient avec 6/32probabilité et les nombres dans la plage 2..5avec5/32 probabilité qui est maintenant plus proche de la valeur souhaitée. L'augmentation du nombre de bits la rend moins significative, lorsqu'elle atteint 63 bits, elle est négligeable.
4. Masquage
En s'appuyant sur la solution précédente, nous pouvons maintenir la distribution égale des lettres en utilisant uniquement autant de bits les plus bas du nombre aléatoire que nécessaire pour représenter le nombre de lettres. Ainsi , par exemple , si nous avons 52 lettres, il faut 6 bits pour le représenter: 52 = 110100b. Nous n'utiliserons donc que les 6 bits les plus bas du nombre renvoyé par rand.Int63(). Et pour maintenir une distribution égale des lettres, nous n'acceptons le nombre que s'il tombe dans la plage 0..len(letterBytes)-1. Si les bits les plus bas sont supérieurs, nous les éliminons et demandons un nouveau nombre aléatoire.
Notez que la probabilité que les bits les plus bas soient supérieurs ou égaux à len(letterBytes)est inférieure à celle 0.5en général ( 0.25en moyenne), ce qui signifie que même si tel est le cas, la répétition de ce cas "rare" diminue les chances de ne pas trouver un bon nombre. Après la nrépétition, la chance que nous n'ayons pas un bon indice est bien inférieure à pow(0.5, n), et ce n'est qu'une estimation supérieure. Dans le cas de 52 lettres, la chance que les 6 bits les plus bas ne soient pas bons est seulement (64-52)/64 = 0.19; ce qui signifie par exemple que les chances de ne pas avoir un bon nombre après 10 répétitions sont 1e-8.
Voici donc la solution:
const letterBytes = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
const (
letterIdxBits = 6 // 6 bits to represent a letter index
letterIdxMask = 1<<letterIdxBits - 1 // All 1-bits, as many as letterIdxBits
)
func RandStringBytesMask(n int) string {
b := make([]byte, n)
for i := 0; i < n; {
if idx := int(rand.Int63() & letterIdxMask); idx < len(letterBytes) {
b[i] = letterBytes[idx]
i++
}
}
return string(b)
}
5. Masquage amélioré
La solution précédente utilise uniquement les 6 bits les plus bas des 63 bits aléatoires renvoyés par rand.Int63(). C'est un gaspillage car obtenir les bits aléatoires est la partie la plus lente de notre algorithme.
Si nous avons 52 lettres, cela signifie que 6 bits codent un index de lettres. Ainsi, 63 bits aléatoires peuvent désigner 63/6 = 10différents indices de lettres. Utilisons tous ces 10:
const letterBytes = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
const (
letterIdxBits = 6 // 6 bits to represent a letter index
letterIdxMask = 1<<letterIdxBits - 1 // All 1-bits, as many as letterIdxBits
letterIdxMax = 63 / letterIdxBits // # of letter indices fitting in 63 bits
)
func RandStringBytesMaskImpr(n int) string {
b := make([]byte, n)
// A rand.Int63() generates 63 random bits, enough for letterIdxMax letters!
for i, cache, remain := n-1, rand.Int63(), letterIdxMax; i >= 0; {
if remain == 0 {
cache, remain = rand.Int63(), letterIdxMax
}
if idx := int(cache & letterIdxMask); idx < len(letterBytes) {
b[i] = letterBytes[idx]
i--
}
cache >>= letterIdxBits
remain--
}
return string(b)
}
6. Source
Le masquage amélioré est assez bon, nous ne pouvons pas améliorer grand-chose. Nous pourrions, mais ne valons pas la complexité.
Maintenant, trouvons autre chose à améliorer. La source des nombres aléatoires.
Il y a un crypto/randpaquet qui fournit une Read(b []byte)fonction, donc nous pourrions l'utiliser pour obtenir autant d'octets avec un seul appel que nous en avons besoin. Cela n'aiderait pas en termes de performances, car il crypto/randimplémente un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé, il est donc beaucoup plus lent.
Restons donc sur le math/randpaquet. Le rand.Randutilise un rand.Sourcecomme source de bits aléatoires. rand.Sourceest une interface qui spécifie une Int63() int64méthode: exactement et la seule chose dont nous avions besoin et utilisée dans notre dernière solution.
Nous n'avons donc pas vraiment besoin d'un rand.Rand(explicite ou global, partagé d'un randpackage), un rand.Sourceest parfaitement suffisant pour nous:
var src = rand.NewSource(time.Now().UnixNano())
func RandStringBytesMaskImprSrc(n int) string {
b := make([]byte, n)
// A src.Int63() generates 63 random bits, enough for letterIdxMax characters!
for i, cache, remain := n-1, src.Int63(), letterIdxMax; i >= 0; {
if remain == 0 {
cache, remain = src.Int63(), letterIdxMax
}
if idx := int(cache & letterIdxMask); idx < len(letterBytes) {
b[i] = letterBytes[idx]
i--
}
cache >>= letterIdxBits
remain--
}
return string(b)
}
Notez également que cette dernière solution ne vous oblige pas à initialiser (amorcer) le global Randdu math/randpaquet car il n'est pas utilisé (et notre rand.Sourceest correctement initialisé / amorcé).
Encore une chose à noter ici: package doc des math/randétats:
La source par défaut est sûre pour une utilisation simultanée par plusieurs goroutines.
Ainsi, la source par défaut est plus lente que Sourcecelle qui peut être obtenue par rand.NewSource(), car la source par défaut doit fournir une sécurité sous accès / utilisation simultanés, tout en rand.NewSource()ne l'offrant pas (et donc le Sourceretour par elle est plus susceptible d'être plus rapide).
7. Utilisation strings.Builder
Toutes les solutions précédentes renvoient un stringdont le contenu est d'abord construit dans une tranche ( []runedans Genesis et []bytedans les solutions suivantes), puis converti en string. Cette conversion finale doit faire une copie du contenu de la tranche, car les stringvaleurs sont immuables, et si la conversion ne faisait pas de copie, il ne pouvait être garanti que le contenu de la chaîne ne serait pas modifié via sa tranche d'origine. Pour plus de détails, voir Comment convertir une chaîne utf8 en [] octet? et golang: [] octet (chaîne) vs [] octet (* chaîne) .
Go 1.10 introduit strings.Builder. strings.Builderun nouveau type que nous pouvons utiliser pour créer un contenu stringsimilaire à bytes.Buffer. Il le fait en interne en utilisant un []byte, et lorsque nous avons terminé, nous pouvons obtenir la stringvaleur finale en utilisant sonBuilder.String() méthode. Mais ce qui est cool, c'est qu'il fait cela sans effectuer la copie dont nous venons de parler ci-dessus. Il ose le faire parce que la tranche d'octets utilisée pour construire le contenu de la chaîne n'est pas exposée, il est donc garanti que personne ne peut la modifier involontairement ou par malveillance pour altérer la chaîne "immuable" produite.
Donc, notre prochaine idée est de ne pas construire la chaîne aléatoire dans une tranche, mais avec l'aide de a strings.Builder, donc une fois que nous avons terminé, nous pouvons obtenir et retourner le résultat sans avoir à en faire une copie. Cela peut aider en termes de vitesse, et cela aidera certainement en termes d'utilisation de la mémoire et d'allocations.
func RandStringBytesMaskImprSrcSB(n int) string {
sb := strings.Builder{}
sb.Grow(n)
// A src.Int63() generates 63 random bits, enough for letterIdxMax characters!
for i, cache, remain := n-1, src.Int63(), letterIdxMax; i >= 0; {
if remain == 0 {
cache, remain = src.Int63(), letterIdxMax
}
if idx := int(cache & letterIdxMask); idx < len(letterBytes) {
sb.WriteByte(letterBytes[idx])
i--
}
cache >>= letterIdxBits
remain--
}
return sb.String()
}
Notez qu'après avoir créé une nouvelle strings.Buidler, nous avons appelé sa Builder.Grow()méthode, en nous assurant qu'elle alloue une tranche interne suffisamment grande (pour éviter les réallocations lorsque nous ajoutons les lettres aléatoires).
8. "Imitation" strings.Builderavec le packageunsafe
strings.Builderconstruit la chaîne dans un interne []byte, comme nous l'avons fait nous-mêmes. Donc, fondamentalement, le faire via un strings.Buildera une surcharge, la seule chose pour laquelle nous sommes passés strings.Builderest d'éviter la copie finale de la tranche.
strings.Builderévite la copie finale en utilisant le package unsafe:
// String returns the accumulated string.
func (b *Builder) String() string {
return *(*string)(unsafe.Pointer(&b.buf))
}
Le fait est que nous pouvons aussi le faire nous-mêmes. Donc, l'idée ici est de revenir à la construction de la chaîne aléatoire dans a []byte, mais lorsque nous avons terminé, ne la convertissez pas stringen retour, mais effectuez une conversion non sécurisée: obtenez un stringqui pointe vers notre tranche d'octets comme données de chaîne .
Voici comment cela peut être fait:
func RandStringBytesMaskImprSrcUnsafe(n int) string {
b := make([]byte, n)
// A src.Int63() generates 63 random bits, enough for letterIdxMax characters!
for i, cache, remain := n-1, src.Int63(), letterIdxMax; i >= 0; {
if remain == 0 {
cache, remain = src.Int63(), letterIdxMax
}
if idx := int(cache & letterIdxMask); idx < len(letterBytes) {
b[i] = letterBytes[idx]
i--
}
cache >>= letterIdxBits
remain--
}
return *(*string)(unsafe.Pointer(&b))
}
(9. Utilisation rand.Read())
Go 1.7 a ajouté une rand.Read()fonction et une Rand.Read()méthode. Nous devrions être tentés de les utiliser pour lire autant d'octets que nécessaire en une seule étape, afin d'obtenir de meilleures performances.
Il y a un petit "problème" avec ceci: de combien d'octets avons-nous besoin? On pourrait dire: autant que le nombre de lettres de sortie. Nous penserions qu'il s'agit d'une estimation supérieure, car un index de lettres utilise moins de 8 bits (1 octet). Mais à ce stade, nous faisons déjà pire (car obtenir les bits aléatoires est la «partie difficile»), et nous obtenons plus que nécessaire.
Notez également que pour maintenir une distribution égale de tous les indices de lettres, il pourrait y avoir des données aléatoires "poubelles" que nous ne serons pas en mesure d'utiliser, donc nous finirions par sauter certaines données, et donc nous retrouverons court quand nous passerons par tous la tranche d'octets. Nous aurions besoin d'obtenir davantage d'octets aléatoires, "récursivement". Et maintenant, nous perdons même l' randavantage du "seul appel au forfait" ...
Nous pourrions "quelque peu" optimiser l'utilisation des données aléatoires que nous acquérons math.Rand(). Nous pouvons estimer le nombre d'octets (bits) dont nous aurons besoin. 1 lettre nécessite des letterIdxBitsbits, et nous avons besoin de nlettres, nous avons donc besoin d' n * letterIdxBits / 8.0arrondir les octets. Nous pouvons calculer la probabilité qu'un indice aléatoire ne soit pas utilisable (voir ci-dessus), nous pourrions donc en demander plus qui sera "plus probable" suffisant (s'il s'avère que ce n'est pas le cas, nous répétons le processus). Nous pouvons traiter la tranche d'octets comme un "flux binaire" par exemple, pour lequel nous avons une belle bibliothèque tierce: github.com/icza/bitio(divulgation: je suis l'auteur).
Mais le code de référence montre toujours que nous ne gagnons pas. Pourquoi en est-il ainsi?
La réponse à la dernière question est car rand.Read()utilise une boucle et continue d'appeler Source.Int63()jusqu'à ce qu'elle remplisse la tranche passée. Exactement ce que fait la RandStringBytesMaskImprSrc()solution, sans le tampon intermédiaire et sans la complexité supplémentaire. C'est pourquoi RandStringBytesMaskImprSrc()reste sur le trône. Oui, RandStringBytesMaskImprSrc()utilise un non synchronisé rand.Sourcecontrairement rand.Read(). Mais le raisonnement s'applique toujours; et qui est prouvé si nous utilisons à la Rand.Read()place de rand.Read()(le premier est également non synchronisé).
II. Référence
Très bien, il est temps de comparer les différentes solutions.
Moment de vérité:
BenchmarkRunes-4 2000000 723 ns/op 96 B/op 2 allocs/op
BenchmarkBytes-4 3000000 550 ns/op 32 B/op 2 allocs/op
BenchmarkBytesRmndr-4 3000000 438 ns/op 32 B/op 2 allocs/op
BenchmarkBytesMask-4 3000000 534 ns/op 32 B/op 2 allocs/op
BenchmarkBytesMaskImpr-4 10000000 176 ns/op 32 B/op 2 allocs/op
BenchmarkBytesMaskImprSrc-4 10000000 139 ns/op 32 B/op 2 allocs/op
BenchmarkBytesMaskImprSrcSB-4 10000000 134 ns/op 16 B/op 1 allocs/op
BenchmarkBytesMaskImprSrcUnsafe-4 10000000 115 ns/op 16 B/op 1 allocs/op
En passant simplement des runes aux octets, nous avons immédiatement un gain de performances de 24% et les besoins en mémoire tombent à un tiers .
Se débarrasser rand.Intn()et utiliser à la rand.Int63()place donne encore 20% coup de pouce de .
Le masquage (et la répétition en cas de gros indices) ralentit un peu (à cause des appels de répétition): -22% ...
Mais lorsque nous utilisons tous (ou la plupart) des 63 bits aléatoires (10 indices d'un rand.Int63()appel): cela accélère beaucoup: 3 fois .
Si nous nous contentons d'un (non-défaut, nouveau) rand.Sourceau lieu de rand.Rand, nous gagnons à nouveau 21%.
Si nous utilisons strings.Builder, nous gagnons un minuscule 3,5% de vitesse , mais nous avons également obtenu une réduction de 50% de l'utilisation et des allocations de mémoire! C'est zonte!
Enfin si nous osons utiliser le package unsafeau lieu de strings.Builder, nous gagnons à nouveau un joli 14% .
Comparer la solution finale à la solution initiale: RandStringBytesMaskImprSrcUnsafe()est 6,3 fois plus rapide que RandStringRunes(), utilise un sixième de la mémoire et deux fois moins d'allocations . Mission accomplie.