Fastutil vs. Trove4j

trove4j是我自己之前一直用的库,fastutil是最近看上的几个开源项目都在用的。它们肯定都比JDK中的标准collection性能要好很多(trove4j和sdk比对的benchmark),但是哪个更好呢?网上也找不到评测。只好自己简单动手做了一个。

版本: trove4j是3.0.3,fastutil是6.5.4

测试机器是64位的centOS

Memory Cost

对两个库的Int型ArrayList分别插入100万,1000万,5000万 和 1一个亿的随机int值,然后调用“jmap -histo pid”查看进程的内存占用情况,很容易找到ArrayList占用的内存:

num     #instances         #bytes  class name
———————————————-
1:           464       83886040  [I
   2:          7440         905960  [C
3:          6317         772064  <constMethodKlass>
4:          6317         763592  <methodKlass>
5:          ……………….

内存占用比对如下:

image

两者占用的内存几乎一致。很奇怪的是,100万int和1000万int占用内存是一样的。当数据比较大时(几千万规模),内存占用大概是原始数据大小的1.*倍。

然后,同样的方法比对了Int型的HashSet 和 HashMap:

image

image

HashSet和HashMap的内部实现其实是差不多的,所以内存占用的曲线很类似。图中明显可以看出,当数据量大的时候,fastutil占用的内存要比trove4j要少,特别的,数据量越大越明显。

HashSet大数据量下,fastutil的内存使用是原始数据的2倍左右,trove4j基本是2.5 ~ 3倍;
HashMap大数据下,fastutil的内存使用是原始数据的1.7倍左右,trove4j是大概2.2倍左右;

Performance

只是简单比较了两者HashMap的查找功能 — 分别对1000万 和 1个亿的HashMap数据执行1000万次的查询,比对程序执行的时间(纵轴的单位是毫秒):

image

总体看,fastutil也要比trove4j更快。

Function

1. fastutil 比 trove4j 提供了更加丰富的collection,例如有SortedMap,有PriorityQueue,这些都是trove4j所不具备的;

2. fastutil的collection都是继承自java.util.collections,因此更容易上手;而trove4j的collection和java.util中的集合都是不兼容的,但是可以通过它提供的一个wrapper转换成java.util.collection;

3. fastutil的库很大,10+MB,相对trove4j要小巧很多;

总体而言,fastutil除了库文件更大以外,其它方面都优于trove4j,可能会是更好的选择。

Advertisements
相册 | 此条目发表在Java, Large Scale分类目录,贴了, , 标签。将固定链接加入收藏夹。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s