【发布时间】:2012-10-10 17:27:26
【问题描述】:
我目前正在研究我的论文项目,设计一个缓存实现以与最短路径图算法一起使用。图算法与运行时相当不一致,因此对整个算法进行基准测试太麻烦了。我必须只专注于对缓存进行基准测试。
我需要进行基准测试的缓存大约是 Map 接口的十几个实现。这些缓存旨在与给定的访问模式(从上面的算法中查询密钥的顺序)很好地配合使用。然而,在一个“小”问题的给定运行中,有几千亿个查询。我需要运行几乎所有这些,才能对基准测试的结果充满信心。
我在将数据加载到内存时遇到了概念性问题。可以创建一个查询日志,它只是在一次算法运行中查询的所有键(它们是 10 个字符的字符串标识符)的磁盘有序列表。这个文件是巨大的。我的另一个想法是将日志分成 1-5 百万个查询的块,并以下列方式进行基准测试:
- 加载 1-5 百万个密钥
- 将开始时间设置为当前时间
- 按顺序查询
- 记录经过的时间(当前时间 - 开始时间)
我不确定这会对缓存产生什么影响。我怎样才能进行热身期?加载文件可能会清除 L1 或 L2 缓存中最后一个块的所有数据。此外,维护一个 1-5 百万元素的字符串数组有什么影响(甚至迭代它会扭曲结果)?
请记住,访问模式很重要!例如,有一些哈希表具有移动到前端启发式,它重新排序表的内部结构。多次运行单个块或无序运行块将是不正确。这使得预热 CPU 缓存和 HotSpot 变得更加困难(我还可以保留一个用于预热但不用于计时的辅助虚拟缓存)。
对于拥有庞大数据集的微基准测试有哪些好的做法?
【问题讨论】:
-
那不是“微基准”。这是一个“宏观基准”。
-
但它是对单一操作进行基准测试 - 哈希表查找。
-
如果你测量毫秒,不要使用
System.currentTimeMillis,使用System.nanoTime():System.currentTimeMillis vs System.nanoTime -
重要的是让它在适当的硬件上变得现实。如果您使用较小的数据集,它将比加载完整的数据集执行得更好。您应该决定数据集应该有多大,并在可以支持该大小的机器上运行测试。如果您没有这么大的机器,您应该购买一台或修改您对所需设备的估计。在更大的机器上运行一个小数据集并估计它在更大的数据集上的运行速度主要是猜测工作。
-
我假设您不是在谈论 Hashtable,因为它不能很好地扩展。我会酌情使用 HashMap 或 ConcurrentHashMap。
标签: java hashtable benchmarking