嵌套映射与多键映射性能

Question

我知道使用多键映射比嵌套映射更高效，但是我编写的测试代码表明嵌套映射比使用平面多键映射更快，内存效率更高。

嵌套地图： - 3个地图，每个地图有7个子地图 - 每个子图有4个子图 - 每个子列表有大约600,000个条目 - 总数：约50,400,000 entires

multikey as simple String map： - 一张50,400,000英寸的巨幅地图

填充嵌套地图的记忆和时间：1462M - ＆gt; 15秒; 记忆和填充多键地图的时间：2138M - ＆gt; 56sec

我不确定我是做错了还是我错过了。

Answer 1

没有基准测试，很难提供帮助。所以它只是一个猜测：也许你只是没有连接字符串来构建单个地图的新密钥。毕竟你创建了> 50M的新字符串。尝试使用专用地图（如apache或guava）快速计算哈希码而不构建重物

Answer 2

我想到了三种可能的解释：

1. 无效的基准。编写一个基准测试非常容易，结果毫无意义。除非我们看到您的基准代码，否则我们无法排除此问题。 （经典的错误是对你要比较的两个案例只进行一次测量......并被JVM预热异常烧毁。）

2. 由于某种原因，多键地图案例中存在大量哈希冲突。

3. 在多键情况下，我假设您的密钥是多个较短密钥的连接。根据键（字符串？）的形成方式（在嵌套映射和多键映射的情况下），您可能会使用更多空间来表示多键映射大小写中的键。这也等同于创建密钥和计算其哈希码的更多时间。

Answer 3

我想我弄清楚为什么嵌套地图看起来比多键地图更有效。每次我在多键映射中创建一个新请求时，我都会创建一个新对象，MultiKey或String。这些＆＃34;查找＆＃34;对象虽然是每次调用的本地对象，但会随着时间的推移逐渐增加，除非gc启动，除非已达到vm max限制，否则它不会启动。使用嵌套地图时，我只是单独按每个键进行查找，因此不会创建在更高范围内已创建的额外对象。