C 嵌套阵列（6维）的替代方案，具有保留O（1）访问的内存间隙

我从运行不同配置的程序中读取统计数据。假设有6种配置（

a

，

b

，…，

f

）。配置可能不会线性变化，因此如果您将测量值视为一个表，那么表中可能会有间隙。问题在于如何在内存中构建这些统计数据

首先想到的是将这些配置读入一个或多个动态分配的6深度阵列：

struct data ******measurements;

现在这个很好用。您的内存开销非常小（只有具有数据的配置才会被实际分配），并且访问时间是

O（1）

除了大多数人不喜欢

******

指针这一事实之外，这还有一个缺点，即添加配置意味着向数组添加维度，除非将对数组的读/写封装在函数中，否则这可能会变得难看。（Write已经封装起来，以便在必要时进行分配，因此这实际上并不是什么大问题）

我想到的另一个想法是使用AVL树或其他东西（我没有实现开销）使用

struct config

到

struct data

的映射。这解决了扩展配置参数的问题，但减少了对

O（log（n））

的访问时间

测试的数量可能会变得相当大，以便

O（log（n））

发挥作用

---

我的问题是：在这里使用6深嵌套数组是否合理？或者有更好的方法吗？

请注意，您当前的设置不是O（1），而是O（k），其中k是维度数。对于平衡树，不管怎样，它都会变成O（log2^k）==O（k）（我假设每个维度都有两个选择；但这并不重要……这里它只是一个常量）。不过，您可能会也可能不会期望平衡树的实现会有更大的开销

您可以做的是尝试使用typedefs和getter/setter函数（最好是内联的）抽象接口，然后使用您想要的任何实现。这样，您就不必处理那么多指针，而且仍然使用内部的任何结构。

是高效存储和查找高维数据的常见选择。维基百科链接的文章只是一个存根，但它指向一个更权威的来源

它们基本上是R-树的改进版本，为最小化重叠而优化

---

我不知道有什么c实现是现成的。

真正的性能瓶颈（除了浪费内存之外）不是计算，而是您将遇到的间接寻址和缓存未命中的数量。在指数和类似的计算中，它们可以占到数十万的主导地位。因此，您最好的选择是减少间接操作的数量，并在计算上投入一些资金。就我所知，这最好通过散列你的6个索引来完成。这将把间接操作减少到两个，首先查找存储在哈希表中的值（可能是指针），然后直接获取您感兴趣的数据。

为什么不使用平面一维数组，自己进行索引计算，而不是让编译器来做呢？使用n维数组会增加缓存未命中的可能性，并可能导致代码性能非常差。采用智能数据结构将为您提供更好的性能。如果你的数据集名义上是常量，你可以用一个好的哈希函数构建一个哈希表，这个哈希表几乎有O（1）个查找，唯一的缺点是你必须先构造它……这不是一个6D数组，而是它的一个模拟。C内置了n维数组，不需要指针开销。@AdamRosenfield，表（有点）稀疏。为所有整体分配内存意味着数十GB的内存。@JensGustedt，请阅读我上面的评论。我无法为表中不存在的超行分配内存。是的，

O（k）

，

k

是配置数。尽管并非所有可能的值都被记录，但每个配置可以是任何整数（比如小于65k）。假设一种配置可能有200个可能的值，另一种配置可能有不同的值。如果您有配置

i

的

xi

可能值，则总共有

n=x1*x2*x3*…*x6

测量值。使用平衡树，这将成为

O（log（n））

，这与

k

完全无关。使用6d数组实际上非常简单，您只需要

写入到

和

从采用6个索引的

（内联）函数中读取。你只是在确认我应该使用数组吗？我只是说如果你抽象了接口，你可以在不改变其他人代码的情况下测试哪种方法在你的特定情况下是最快的。这很有趣。我也在R-树上阅读。但在我看来，鉴于我的数据的表格性质，这将简化为数组和树方法的混合。例如，前四种配置上的平衡树以及每组内部的二维阵列。你怎么认为？