我正在实现一个VM编译器，当然，我已经到了实现交换机的地步。同样自然地，对于短开关，顺序查找阵列将是最佳的，但更大的开关呢？
到目前为止，我已经提出了一个数据结构，它给我一个非常好的查找时间。我不知道那个结构的名称，但它类似于二叉树但是monolith，不同之处只是它适用于静态的整数集，不能添加或删除。它看起来像一个表，其中值增加到顶部和右侧，这是一个例子：
整数-89，-82，-72，-68，-65，-48，-5,0,1,3,7,18,27,29,32,37,38,42,45,54 ，76,78,87,89,92
和表格：
-65 3 32 54 92
-68 1 29 45 89
-82 -5 18 38 78
-89 -48 7 37 76
这给了我最糟糕的width + height次迭代案例。假设情况为37，-65小于37，所以向右移动，向右移动3次，向右移动32次，向右移动54次，向下移动向下移动（步长为宽度，因为它是无论如何顺序阵列，45更大，所以向下移动，38更大，所以向下移动，我们在7跳中有37个。
是否有更快的查找算法？
此外，这种安排是否有名称？我自己想出了它，但最有可能是其他人在我之前做到了，所以它很可能已经命名了。
编辑：好的，就我而言，“完美哈希”将为我提供更好的理论性能。但这将如何在现实生活中发挥作用？如果我理解正确的话，两个级别的“完美散列”将相当分散而不是连续的内存块，因此虽然理论上的复杂性较低，但在获取内存之前可能存在数十甚至数百个周期的惩罚。相比之下，较慢的理论最坏情况场景实际上会表现得更好，因为它比完美的哈希更容易缓存...或者不是吗？答案 0 :(得分：2)
在各种备选方案中实施交换机时，您有以下几种选择：
1, 2, 3, 20000, 20001, 20002，则可以执行单个if将您带到1秒或20,000秒，然后使用两个平面查找数组。100, 200, 300, 400, 500, 600，请将数字除以100，然后选择平面查找数组。你的算法类似于二元搜索，因为它来自“分而治之”的家庭。这些算法具有对数时间复杂度，这对于交换机来说可能是不可接受的，因为它们应该是O(1)。
答案 1 :(得分：0)
是否有更快的查找算法？
二进制搜索速度更快。
二进制搜索在log2中完成（w * h）= log2（w）+ log2（h）。
您的算法在w + h完成。