切片最快的集合是什么？
我需要执行以下操作：
collection.slice(x, y)
....
collection.slice(x+1, y+1)
...
collection.slice(x+n, y+n)
or
collection.slice(x-n, y-n)
通常需要执行这部分代码，因此我希望使其尽可能快。我应该选择什么集合？ （可以是不可变的）。
PS 性能特征页面“应用”特征负责用于切片？
PPS 寻找专门针对该主题的文章、手册。
I need to execute the following operation:
collection.slice(x, y)
....
collection.slice(x+1, y+1)
...
collection.slice(x+n, y+n)
or
collection.slice(x-n, y-n)
Very often execution of this part of code is expected, so I want to make it as fast as possible. What collection should I choose? (can be immutable).
P.S. on Performance Characteristics page "apply" characteristic is responsible for slicing?
P.P.S looking for articles, manuals dedicated on subject.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
答案在某种程度上取决于 x 和 y 的距离，但通常最好使用普通数组。如果您不需要对切片执行任何操作，则使用视图可能会更快，但使用视图访问速度会较慢，因此最好远离它们。
无论如何，您肯定想要一些具有快速“应用”（对数或恒定时间）的东西，并且介于
Array、Vector和ArrayBuffer、>Array是最快的，ArrayBuffer大约慢 50%，而Vector在切片和使用切片后的每个元素方面又慢了大约两倍。另外，请考虑
滑动是否能达到您想要的效果。虽然不如直接切片那么快，但是非常方便。The answer depends somewhat on how far apart x and y are, but you are generally best off using plain arrays. If you don't need to do anything with the slices, using views might be faster, but access is slower with views, so it's probably better to stay away from them.
Anyway, you certainly want something with fast "apply" (log or constant time), and between
Array,Vector, andArrayBuffer,Arrayis the fastest,ArrayBufferis about 50% slower, andVectoris about twice as slow again for slicing and using every element that you've sliced.Also, consider whether
slidingwill do what you want. It's not as fast as the direct slicing, but it's awfully convenient.嗯，
Vector具有logN性能，但根据您的要求，常数因子可能太重。另一方面，也许
range能满足您的需求？如果确实如此，那么SortedMap很可能会以较小的常数因子提供logN性能。或许。Well,
VectorhaslogNperformance, though the constant factor may be too heavy depending on your requirements.On the other hand, maybe
rangedoes what you want? If it does, then aSortedMapmight well provide alogNperformance with smaller constant factor. Maybe.