我必须实现一种算法来分解体素中的 3D 体积。该算法首先确定哪些顶点位于切割计划的每一侧，然后在第二步中哪条边穿过切割计划。
这个过程可以通过使用排序列表的好处来优化。识别分裂点是O log(n)。但是我必须为每个轴维护一个这样的排序列表，这个列表用于顶点和边。由于这是为了供 GPU 使用而实现的，所以我对内存管理（即 CUDA）也有一些限制。强加了侵入性列表 M/树和 C。
通过完整的“体素化”，我希望最终得到约 4000 个点和 12000 个边缘。幸运的是，这可以通过使用更智能的策略来优化，以摆脱处理过的体素并订购剩余体积切割以将其数量保持在最低限度。在这种情况下，我希望有少于 100 个点和 300 个边。这使得流程管理起来更加复杂，但最终可能会变得更加高效。
因此，问题是帮助我确定标准，以确定与简单的侵入式链接列表相比，使用排序数据结构的好处何时值得付出努力和复杂性开销。
chmike，这听起来确实像是您想要先以更简单的方式做的事情，然后看看它的行为方式。一旦你至少进入大容量（你似乎没有），任何类型的 GPU 体素化方法都对系统细节非常脆弱。在你的鞋子里，我肯定首先想要简单的实现，如果没有其他原因要检查......
这个问题总是归结为哪个运算符最常见，访问或添加。如果你有一个无序列表，添加它不需要时间，访问特定项目需要额外的时间。如果您有一个排序列表，添加到它需要更多时间，但访问它会更快。
大多数应用程序花费大部分时间访问数据，而不是添加数据，这意味着创建排序列表的（运行）时间开销通常会被访问列表所节省的时间平衡或覆盖。如果您的数据中有大量流失（听起来并不像这样），那么维护排序列表不一定是可取的，因为您将不断地将列表视为可观的 CPU 成本。
数据结构的复杂性只有在它们不能以有用的方式排序时才重要。如果它们可以被排序，那么你将不得不通过启发式
访问次数：更改次数
确定排序是否是一个好主意。
在考虑了所有答案后，我发现后一种用于避免重复计算的方法最终效率会降低，因为需要在数据结构中进行维护和导航。此外，初始方法很容易与一些小的内核例程并行化，因此更适合 GPU 实现。
回顾我最初的方法，我还发现了重要的优化机会，这些机会使体积削减方法远远落后。
因为我必须选择一个答案，所以我选择了 devinb，因为他回答了这个问题，但是 Simon 的评论，得到了 Tobias Warre 评论的支持，对我来说同样有价值。
感谢大家帮我解决这个问题。堆栈溢出是一项令人印象深刻的服务。