Go の `map[string]string` では文字列の長さがメモリ使用量に影響を与えないように見えるのはなぜですか?

Golang での文字列メモリ使用量

可能な値が 2 つだけ (「A」または「B」) のマップ[文字列]文字列を使用してコードを最適化すると、メモリ使用量が削減されます。 map[string]bool に変更すると、パフォーマンスが明らかに向上するように思えます。しかし、テストの結果、驚くべきことが判明しました。長い文字列 ("a2") のメモリ使用量は、単一文字の文字列 ("a") と何ら変わりません。

説明

理解するにはこの動作では、unsafe.Sizeof() は参照されるデータ構造のサイズを考慮しないことに注意することが重要です。代わりに、渡された値の「浅い」サイズのみを報告します。

Go では、マップはデータ構造へのポインターです。 unsafe.Sizeof(somemap) を呼び出すと、マップ内の要素によって使用される実際のメモリではなく、このポインターのサイズが返されます。

同様に、Go の文字列は、ポインターと長さを含むヘッダーによって表されます。 unsafe.Sizeof(somestring) を呼び出すと、文字列の長さに関係なく、このヘッダーのサイズが返されます。

文字列のメモリ要件

文字列値をメモリに格納するために必要な実際のメモリは、UTF-8 でエンコードされたバイト シーケンスの長さにヘッダーのサイズを加えたものと等しくなります。これを計算するには、次の式を使用できます。

stringSize = len(str) + int(unsafe.Sizeof(str))

文字列のスライスとメモリ使用量

文字列のスライスにより、バッキング配列を指す新しいヘッダーが作成されることを覚えておくことも重要です。オリジナルの文字列。これは、スライスされた文字列 (s2) が小さい場合でも、元の文字列 (s) のバッキング配列全体がメモリ内に保持されることを意味します。

以上がGo の `map[string]string` では文字列の長さがメモリ使用量に影響を与えないように見えるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。