Scala（或Java）中的自适应映射保留插入顺序

Question

我想找到并重用（如果可能）具有以下属性的地图实现：

1. 虽然条目数量很少，但说＆lt; 32，底层存储应该在这样的数组中完成[key0，val0，key1，val1，...]这种存储方案避免了许多小的Entry对象，并提供极快的查找（甚至是连续扫描！）现代CPU由于CPU的缓存没有失效而且没有指针间接到堆中。

2. 地图应保持键/值对的插入顺序，而不管与LinkedHashMap类似的条目数

我们正在研究Scala中大量（数百万个节点/边缘）图形的内存表示，并且使用这样的Map可以让我们以更有效的方式存储节点/边缘属性以及每个节点的边缘对于99％以上的节点和边缘，它们具有少量属性或邻居，同时保留属性和边缘的时间顺序插入顺序。

如果有人知道具有这些特征的Scala或Java地图，我将非常感激。

感谢名单

Answer 1

虽然我不知道任何完全符合您要求的实现，但您可能有兴趣在Jakarta Commons库中查看Flat3Map（source）。

不幸的是，Jakarta库已经过时了（例如，在最新的稳定版本中不支持泛型，虽然它很有希望看到这在主干中发生变化）而且我通常更喜欢Google Collections，但它可能值得花时间看看Apache是​​如何实现的。

不幸的是，Flat3Map不保留密钥的顺序，但我确实对您的原始帖子有建议。我建议使用并行数组，而不是将键和值存储在像[key0, val0, key1, val1, ...]这样的单个数组中;也就是说，一个数组[key0, key1, ...]而另一个数组[val0, val1, ...]。通常我不是并行数组的支持者，但至少这样你就可以有一个K类型的数组，你的密钥类型，另一个类型为V的数组，你的值类型。在Java级别，它有自己的一组瑕疵，因为你不能使用语法K[] keys = new K[32];相反，您需要使用a bit of typecasting。

Answer 2

如果LinkedHashMap对你来说太慢了，你是否用profiler测量过？也许你不需要那张新地图 - 过早的优化是所有邪恶的根源。 无论如何，在第二个甚至最佳优化的映射中处理数百万或更多的数据可能太慢，因为在这种情况下，每个方法调用都会降低性能。然后，您所能做的就是将您的算法从Java集合重写为数组（即int - ＆gt;对象映射）。

Answer 3

在java下你可以维护一个二维数组（电子表格）。我写了一个程序，它基本上定义了一个带有3个数据库的2 d数组，以及3个用于查找数据的颜色。三个颜色是testID，SubtestID和Mode。这允许我基本上通过testid和模式或任何组合查找值，或者我也可以通过静态放置来引用。该表在启动时加载到内存中并由程序引用。它无限可扩展，可根据需要添加新值。

如果您有兴趣，我今晚可以发布一个代码源示例。

另一个想法可能是在程序中维护数据库。数据库旨在组织大量数据。