结构体数组或一个包含其每个属性的数组的结构体
在设计 API 时，我可能希望将详细信息（例如正在运行的进程）保留到我自己的自定义结构中。但是，如果我要对超过 1 个进程执行此操作，这意味着我需要多个结构，我应该有一个结构数组还是一个结构，其中每个属性都有一个数组（例如 startTime、processName 和其他进程属性）有兴趣）。
哪种方式对性能更好，对 api/类库更好？
谢谢
When designing an API, I may want to persist details (Eg of a process running) into my own custom struct. However, if I am going to do this for more than 1 process, meaning I need several structs, should I have an array of structs or one struct with an array for each of its properties (eg startTime, processName and other process properties I am interested in).
Which way is better for performance and better for an api/class library?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
恕我直言，尽管实例化所有结构会影响性能，但您应该执行一系列结构。将一种状态存储在一个结构中的组织意义远远超过了性能损失，并且将一个结构与一堆数组一起使用并简单地为每个进程分配多个数组中的索引非常混乱，并且调试起来可能会非常痛苦。
IMHO you should do an array of structs despite the performance hit you take for instansiating all of the structs. The organizational sense of one state being stored in one struct far outweighs the loss of performance, and using one struct with a bunch of arrays and simply assigning each process an index in a number of arrays is very messy and can be a huge pain to debug.
您可能会考虑使用
class而不是struct，我会使用类列表。You might consider using a
classrather than astructand I would use a list of classes.Eric Lippert 有一些反对在 API 中使用数组的论点。对我来说更引人注目的原因之一是为什么您希望保持集合大小固定，但允许消费者修改内容。您可以此处查看更多内容。
最终，您可能希望使用数组在内部存储它们，但我会避免通过 API 公开这一点。如果人们需要枚举，请使用 IEnumerable；反而。
Eric Lippert has a few arguments against using arrays in an API. One of the more compelling to me is why you'd want to keep the collection size fixed, but allow consumers to modify the contents. You can see more here.
Ultimately, you may want to store them internally using arrays, but I would avoid exposing this through the API. If people need to enumerate, use IEnumerable<T> instead.
从数据存储的角度来看，如果访问一个项目的所有部分的频率比访问一组连续项目中的某个特定部分的频率更高，则使用结构体数组的缓存行为会更好。
一个更有趣的问题是如何公开数据。如果将结构公开为索引器，则任何想要更改结构字段的人都必须读出结构，更改临时副本中的字段，然后将其写回。您可以公开方法来读取/写入单个属性，但“foo.setBar(100, 23)”似乎比“foo(100).Bar=23”不太自然。太允许后一种语法，我建议也许让索引器返回一个具有两个私有字段“root”和“index”的结构，以及该结构的每个字段的属性，以便例如索引器的 Bar 属性的设置器将执行 root.setBar(index, value)。索引器还应该有一个“asWhateverStructType”属性来获取/设置整个结构。
From a data-storage standpoint, if one will frequently be accessing all the parts of an items more often than one would be accessing some particular part from a group of consecutive items, caching behavior will be better with an array of structs.
A more interesting question is how to expose the data. If you expose the struct as an indexer, anyone wanting to change a field of the struct will have to read out the struct, change the field in their temporary copy, and write it back. You could expose methods to read/write individual properties, but "foo.setBar(100, 23)" seems rather less natural than "foo(100).Bar=23". Too allow the latter syntax, I'd suggest perhaps having the indexer return a struct with two private fields, "root" and "index", and properties for each field of the struct so that e.g. the setter for the Bar property of the indexer would perform root.setBar(index, value). The indexer should also have an "asWhateverStructType" property to get/set the struct as a whole.