例如，有些物件具有相似的結構但不完全相同。
const arr = [
{ name: 'john', age: 12 },
{ name: 'marry', age: 24, married: true }
]
或者
const obj = {
john: { age: 12 },
marry: { age: 24, married: true }
}
假設約翰沒有結婚，所以他不需要married鑰匙。（盡管為了一致性，將“已婚”設定為假可能會更好。）這可能不是一個完美的例子，但在任何一種情況下，都包含married鍵并保持物件結構的一致性有助于提高性能嗎？例如，也許它可以幫助 CPU 更快地將資料寫入記憶體......？
uj5u.com熱心網友回復：
除了標準免責宣告（這里所說的一切可能在引擎之間，甚至在同一引擎的不同版本之間有所不同，這只是一個實作細節，在優化之前測量，在優化之前三思而后行以犧牲可讀性為代價，等等等等……），我認為用謹慎的“是”來回答這個問題是合理的。至少，確保物件始終具有相同的形狀應該沒有什么壞處。
特別是在 V8 的情況下，有一些眾所周知的隱藏類優化，它根據物件的動態分析內容優化物件的記憶體布局。運行時物件形狀越少，要跟蹤的隱藏類就越少，而那些可以在更多情況下重用的隱藏類。引擎也不必為多個隱藏類查找快取資料，這可以減少 CPU 快取爭用。
構成物件“形狀”的因素當然會有所不同，但您可以預期有許多相關的特征：
- 存在哪些屬性；
- 將屬性添加到物件的順序（對此的敏感性有時稱為路徑依賴）；
- 施工后是否修改屬性；
- 這些屬性中保存的值的型別，甚至這些型別的特定子范圍（例如，已知 V8 存盤范圍 [-2 31 , 2 31）中的整數比其他數字更有效，即使名義上是 JS 數字型別涵蓋所有 IEEE 754 雙精度）。
盡管以上內容主要基于 V8，但您可以期望任何其他優化 JavaScript 引擎基于物件形狀執行大致相似的優化。事實上，即使是相對簡單的 QuickJS 也會快取物件形狀以加快屬性查找速度。
并以確保概念上相同“型別”的物件具有一致形狀的方式撰寫代碼（例如，通過始終將它們構造在代碼中的一個位置，其中相同的屬性以相同的順序添加）時間甚至不應該損害可讀性——相反，它甚至可能使代碼更容易理解。與其他一些微優化不同，我認為這至少在某種程度上絕對值得做。
uj5u.com熱心網友回復：
性能優勢是：
- 幾乎可以肯定很小，而且
- 幾乎可以肯定 JS 引擎之間會有所不同
并且不值得擔心，除非：
- 您的代碼運行速度太慢，并且
- 分析涉及與創建/操作這些物件有關的代碼部分
真正關心的是可維護性。為邏輯相關的物件維護一組一致的屬性是一件好事，即使它是不必要的；如果有人想在您的代碼上進行構建，那么如果他們可以依賴給定物件集合的一組固定屬性，那就太好了。默認始終包含額外的屬性；如果您獲得性能提升，那只是肉汁。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/527566.html