我正在从运行具有不同配置的程序中读取统计数据。假设有 6 种配置（a、b、...、f）。配置可能不会线性变化，因此，如果您将测量值视为表格，则表中可能存在间隙。问题是关于在内存中构建这些统计数据。
首先想到的是将这些配置读取到动态分配的 6 深度数组或阵列：
struct data ******measurements;
现在这工作正常。您的内存开销非常少（实际上只会分配具有数据的配置），并且访问时间O(1) 。
除了大多数人不喜欢******指针之外，这还有一个缺点，即添加配置意味着向数组添加维度，除非将数组的读/写封装在函数中，否则这可能会变得丑陋。（Write 已经被封装起来，以便在必要时处理分配，所以这实际上没什么大不了的）。
我想到的另一个想法是使用struct config映射来struct data使用 AVL 树或其他东西（我已经有了，所以没有实现开销）。这解决了扩展配置参数的问题，但减少了访问时间O(log(n))。
测试的数量可能会变得相当大，以使O(log(n))发挥作用。
我的问题是：在这里使用 6 深度嵌套数组是否合理？还是有更好的方法可以做到这一点？
请注意，您当前的设置不是 O（1），而是 O（k），其中 k 是维度数。对于平衡树，无论如何它都会转到 O（log 2^k） == O（k）（我假设每个维度都有两个选择;但没关系......这里只是一个常数）。不过，您可能会也可能不会期望在实现平衡树时产生更大的开销。
你可以做的是尝试用typedefs和getter/setter函数（最好是内联的）来抽象接口，然后使用你想要的任何实现。然后，您不必处理太多指针，并且仍然可以使用内部的任何结构。
X 树是高效存储和查找高维数据的常见选择。链接的维基百科文章只是一个存根，但它指向更权威的来源。
它们基本上是R树的改进版本，针对最小化重叠进行了优化。
我不知道手头的c实现。
真正的性能瓶颈（除了浪费内存）不是计算，而是您将遇到的间接和缓存未命中的数量。这些可以主导数百到数千倍的指数计算和类似的东西。因此，最好的选择是减少间接寻址的数量，并在计算中投入一点。据我所知，最好通过散列您的 6 个索引来完成。这会将您的间接寻址减少到两个，首先查找存储在哈希表中的值（可能是指针），然后直接获取您感兴趣的数据。