Beim Optimieren von Code mit einem Map[string]string mit nur zwei möglichen Werten („A“ oder „B“) wird dieser reduziert zu einem map[string]bool scheint eine offensichtliche Verbesserung für die Leistung zu sein. Tests ergaben jedoch eine überraschende Beobachtung: Die Speichernutzung einer langen Zeichenfolge („a2“) unterscheidet sich nicht von der einer Einzelzeichenfolge („a“).
Zum Verständnis Bei diesem Verhalten ist zu beachten, dass unsafe.Sizeof() die Größe der referenzierten Datenstrukturen nicht berücksichtigt. Stattdessen wird nur die „oberflächliche“ Größe des übergebenen Werts gemeldet.
In Go sind Karten Zeiger auf eine Datenstruktur. Der Aufruf von unsafe.Sizeof(somemap) gibt die Größe dieses Zeigers zurück, nicht den tatsächlichen Speicher, der von den Elementen innerhalb der Map verwendet wird.
In ähnlicher Weise werden Zeichenfolgen in Go durch Header dargestellt, die einen Zeiger und eine Länge enthalten. Der Aufruf von unsafe.Sizeof(somestring) gibt die Größe dieses Headers zurück, die unabhängig von der Länge der Zeichenfolge ist.
Der tatsächlich erforderliche Speicher, um einen Zeichenfolgenwert im Speicher zu speichern ist gleich der Länge seiner UTF-8-codierten Bytesequenz plus der Größe seines Headers. Um dies zu berechnen, können Sie die folgende Formel verwenden:
stringSize = len(str) + int(unsafe.Sizeof(str))
Es ist auch wichtig zu bedenken, dass beim String-Slicing ein neuer Header erstellt wird, der auf das Backing-Array des verweist Originalsaite. Dies bedeutet, dass selbst wenn die zerlegte Zeichenfolge (s2) klein ist, das gesamte Hintergrundarray der ursprünglichen Zeichenfolge(n) weiterhin im Speicher erhalten bleibt.
Das obige ist der detaillierte Inhalt vonWarum scheint die String-Länge keinen Einfluss auf die Speichernutzung in Gos „map[string]string' zu haben?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!