與我在 C++ 中學到的類似，我相信填充會導致兩個結構的實例大小不同。type Foo struct { w byte //1 byte x byte //1 byte y uint64 //8 bytes}type Bar struct { x byte //1 byte y uint64 //8 bytes w byte// 1 byte}func main() { fmt.Println(runtime.GOARCH) newFoo := new(Foo) fmt.Println(unsafe.Sizeof(*newFoo)) newBar := new(Bar) fmt.Println(unsafe.Sizeof(*newBar))}輸出：amd641624定義結構成員時是否有經驗法則可以遵循？（如類型大小的升序/降序）是否有我們可以通過的編譯時優化，可以自動處理這個問題？或者我根本不應該擔心這個？
3 回答
幕布斯6054654
TA貢獻1876條經驗 獲得超7個贊
目前沒有編譯時優化；這些值在 x64 上填充為 8 個字節。
您可以手動排列結構以最佳利用空間；通常是從較大的類型變為較小的類型；例如，8 個連續的字節字段將僅使用 8 個字節，但單個字節將被填充到 8 字節對齊，請考慮： https: //play.golang.org/p/0qsgpuAHHp
package main
import (
"fmt"
"unsafe"
)
type Compact struct {
a, b uint64
c, d, e, f, g, h, i, j byte
}
// Larger memory footprint than "Compact" - but less fields!
type Inefficient struct {
a uint64
b byte
c uint64
d byte
}
func main() {
newCompact := new(Compact)
fmt.Println(unsafe.Sizeof(*newCompact))
newInefficient := new(Inefficient)
fmt.Println(unsafe.Sizeof(*newInefficient))
}
如果您考慮到這一點；您可以優化結構的內存占用。
慕尼黑的夜晚無繁華
TA貢獻1864條經驗 獲得超6個贊
或者我根本不應該擔心這個？
是的你應該。
這也稱為機械同情（請參閱此Go Time 播客片段），因此它還取決于您正在編譯的硬件架構。
如圖所示：
“天字節對齊回來咬我”（2014 年 1 月）
《關于 Go 切片值的內存對齊》（2016 年 7 月）
Go 切片中的值是 16 字節對齊的。它們不是 32 字節對齊的。
Go 指針是字節對齊的。
守著一只汪
TA貢獻1872條經驗 獲得超4個贊
這取決于您正在開發的應用程序的類型以及這些結構的使用。如果應用程序需要滿足一些內存/性能標準，您絕對應該關心內存對齊和填充，但不僅如此 - 有一篇很好的文章https://www.usenix.org/legacy/publications/library/proceedings/als00/2000papers/論文/full_papers/sears/sears_html/index.html突出了最佳 CPU 緩存使用的主題以及結構布局和性能之間的相關性。它突出了緩存行對齊、錯誤共享等。
還有一個不錯的 golang 工具https://github.com/1pkg/gopium可以幫助自動化這些優化，看看吧！
- 3 回答
- 0 關注
- 220 瀏覽
添加回答
舉報
0/150
提交
取消