我可以假设类字段将位于 CPU 缓存中吗？
在C＃中，我总是想知道内存访问模式如何影响我的应用程序的性能。 例如，我有一个具有5个字段的课程，并且在该类的函数中，我访问了所有类。 因此，我的问题是，当我访问这些字段时，它们将已经进入缓存（因此我会受到缓存的命中率），否则CPU需要从RAM中添加该数据（因此我会发现Cache Miss）。而且，如果您有一个资源，我可以在C＃中阅读有关此类内存管理技巧的信息，请提供一个链接。
In C# I always wonder how memory access patterns effects performance of the my application.
For example I have a class that has 5 fields and in a function of that class I access all of them.
So my question is when I access these fields are they going to be already in cache (so I get cache hit) or CPU needs to go add pull that data from RAM (so I get cache miss). And if you have a resource that I can read about this kind of memory management tricks in C# please provide a link.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，不用担心。编译器编写者和 CPU 设计者都很聪明，通常会确保缓存得到充分利用。
实际上，一个类将依次存储所有字段。由于您总是一次从内存中获取完整的缓存行，因此很可能会从单个内存加载中获取并缓存所有字段。
重要的是，如果您有许多可能存储在内存中不同位置的小对象。例如，当使用链表存储小对象时。请参阅 Bjarne Stroustrup 讲座为什么应该避免使用链接列表。因此，某些算法受益于使用值类型和数组而不是对象。一个例子是类似于二进制堆，虽然它可以用对象来实现对于每个节点，使用单个数组将节省空间并确保所有节点在内存中都是连续的，这通常有助于提高缓存效率。
但只有在存在实际性能问题时才进行优化，然后确保首先测量性能。
In general, don't worry about it. The compiler writers and CPU designers are smart and typically ensures the cache is well used.
In practice a class will store all fields one after each other. And since you always fetch a full cache-line from memory at a time, it is likely that all fields will be fetched and cached from a single memory load.
Where it can matter is if you have lots of small objects that may be stored at different places in memory. For example when using linked lists to store small objects. See Bjarne Stroustrup lecture Why you should avoid Linked Lists. So some algorithms benefit from using value types and arrays instead of objects. An example would be something like a binary heap, while it could be implemented with an object for each node, using an single array will save space and ensure all nodes are sequential in memory, and that typically help with cache efficiency.
But only optimize things when there is an actual performance problem, and then make sure to measure the performance first.