我正在研究我的论文项目，设计一个用于最短路径图算法的缓存实现。图算法与运行时相当不一致，因此对整个算法进行基准测试太麻烦了。我必须专注于仅对缓存进行基准测试。
我需要进行基准测试的缓存大约是十几个Map接口的实现。这些高速缓存旨在与给定的访问模式（从上面的算法查询密钥的顺序）很好地工作。但是，在“小”问题的给定运行中，存在几千亿个查询。我需要运行几乎所有这些来对基准测试的结果充满信心。
我遇到了将数据加载到内存中的概念问题。可以创建一个查询日志，它只是在一次运行算法中查询的所有密钥（它们是10个字符的字符串标识符）的盘上有序列表。此文件 huge 。另一个想法是将日志分成1-5百万个查询块，并以下列方式进行基准测试：
我不确定这会对缓存产生什么影响。我怎么能进行预热期？加载文件可能会清除最后一个块的L1或L2缓存中的任何数据。另外，维持一个1-5百万个元素字符串数组有什么影响（甚至迭代它会使结果偏斜）？
请记住，访问模式很重要！例如，有一些哈希表具有从前到右的启发式方法，它重新排序表的内部结构。多次运行单个块或者无序运行块会不正确。这使得加热CPU缓存和HotSpot变得更加困难（我还可以保留用于加温而不是计时的辅助虚拟缓存）。
使用巨型数据集的微基准测试的优良做法是什么？
答案 0 :(得分：1)
如果我正确理解了问题，那么如何在一台计算机上加载查询日志（如果没有足够的内存，可能以块为单位），并通过专用网络（交叉电缆将其流式传输到运行基准测试的计算机） ，可能），因此您在被测系统与测试代码/数据之间的干扰最小......？
无论您使用何种解决方案，都应该尝试多次运行，以便评估可重复性 - 如果您没有获得合理的可重复性，那么您至少可以检测到您的解决方案不合适！
更新：re：批处理和计时 - 实际上，您可能最终会采用某种形式的细粒度批处理，至少可以有效地通过网络获取数据。如果您的数据属于自然大的“群体”或阶段，那么我会单独计时检查异常，但最依赖于整体时间。我认为计时小批量的数量并不会带来太多好处（假设您已经运行了数百万）。
即使您在一台具有大量RAM的计算机上运行所有内容，也可能值得将数据加载到一个JVM中并将测试中的代码加载到另一个JVM上，以便缓存JVM上的垃圾收集不会（直接）受到保存查询日志所需的大堆。