小编典典
现在的问题是关于存储大量数据,这些数据可以int在Map中使用诸如的原始类型表示。在我看来,这里的某些答案非常容易引起误解。让我们看看为什么。
我从trove修改了基准,以测量运行时和内存消耗。我还将PCJ添加到该基准测试中,这是另一个用于原始类型的集合库(我广泛使用了该库)。“官方的” trove基准测试没有将IntIntMaps与Java Collection的进行比较Map,从技术的角度来看,存储Integers和存储可能ints并不相同。但是用户可能不在乎此技术细节,他想存储可ints高效表示的数据。
首先是代码的相关部分:
new Operation() {
private long usedMem() {
System.gc();
return Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
}
// trove
public void ours() {
long mem = usedMem();
TIntIntHashMap ours = new TIntIntHashMap(SET_SIZE);
for ( int i = dataset.size(); i-- > 0; ) {
ours.put(i, i);
}
mem = usedMem() - mem;
System.err.println("trove " + mem + " bytes");
ours.clear();
}
public void pcj() {
long mem = usedMem();
IntKeyIntMap map = new IntKeyIntOpenHashMap(SET_SIZE);
for ( int i = dataset.size(); i-- > 0; ) {
map.put(i, i);
}
mem = usedMem() - mem;
System.err.println("pcj " + mem + " bytes");
map.clear();
}
// java collections
public void theirs() {
long mem = usedMem();
Map map = new HashMap(SET_SIZE);
for ( int i = dataset.size(); i-- > 0; ) {
map.put(i, i);
}
mem = usedMem() - mem;
System.err.println("java " + mem + " bytes");
map.clear();
}
我认为数据来自原始数据ints,这似乎很理智。但这意味着对Java util的运行时惩罚,因为自动装箱对于原始集合框架不是必需的。
gc()在WinXP jdk1.6.0_10上的运行时结果(当然没有调用):
100000 put operations 100000 contains operations
java collections 1938 ms 203 ms
trove 234 ms 125 ms
pcj 516 ms 94 ms
尽管这似乎已经很严峻,但这并不是使用这种框架的原因。
原因是内存性能。包含100000int个条目的Map的结果:
java collections oscillates between 6644536 and 7168840 bytes
trove 1853296 bytes
pcj 1866112 bytes
与原始集合框架相比,Java集合需要的内存是其三倍以上。也就是说,您可以在内存中保留三倍的数据,而无需诉诸于磁盘IO,这会严重降低运行时性能。这很重要。阅读可扩展性以了解原因。
以我的经验,高内存消耗是Java的最大性能问题,这当然也会导致运行时性能下降。原始集合框架确实可以在这里提供帮助。
因此:不,java.util不是答案。在询问效率时,向Java集合“添加功能”并不是重点。同样,现代的JDK集合也不会“超越专业的Trove集合”。
免责声明:这里的基准还远远不够完善,也不是完美的。这是为了让我明白我在许多项目中都曾经历过的观点。如果您处理大量数据,则原始集合足够有用以容忍可疑的API 。
2020-11-16