内存的物理原理（又名：JavaScript能实现ECS吗？）
本文深入探讨了面向对象编程（OOP）与实体组件系统（ECS）在内存布局和CPU缓存性能上的根本差异。作者通过JavaScript基准测试，分析了ECS如何通过改善数据局部性来减少缓存未命中，从而提升性能。文章不仅解释了ECS在游戏开发中的优势，还展示了即使在JavaScript这类高级语言中，内存访问模式依然对性能有显著影响。
背景速读
- 本文的核心问题是：在 JavaScript 中，**ECS（实体-组件-系统）架构** 相比传统的 **OOP（面向对象编程）**，在性能上到底有没有优势？ECS 是一种起源于游戏开发的数据组织方式，强调把“数据”（组件）和“逻辑”（系统）分离，数据通常连续存储在数组中，以利用 CPU 缓存。OOP 则把数据和逻辑封装在对象里，对象在内存中可能分散各处。
- 作者用 JavaScript 写了一个物理模拟的基准测试，分别用 ECS 风格和 OOP 风格实现，对比它们的运行速度。结果 ECS 版本显著更快——这在 C++ 这类底层语言中早有定论，但在 JS（一个没有手动内存控制、没有真正缓存感知的垃圾回收语言）中，结论一直有争议。
- 这篇文章之所以值得关注，是因为它用实际数据论证了：即便在 JavaScript 里，数据布局（data layout）对性能的影响依然巨大。这对前端游戏开发（如使用 PixiJS、Three.js 的项目）、高性能 Web 应用，以及任何想在 JS 里做大量实体更新的开发者都有直接参考价值。