Tag: 卡尺

JDK8 LocalDate.toEpochDay的性能下降奇怪

如果我们最终得到一个带JDK8的快速日期时间库，我很好奇。 几乎所有的LocalDate计算都使用toEpochDay所以我查看了源代码 ，大量的分支和分支让我好奇，如果我能做得更好的话。 我消除了一些分支和除了一个分区以外的所有分支，但是加速比预期更差。 所以我的第一个问题是如何使用多次除法的算法只需要大约30个周期（吞吐量）。 霍尔格的评论似乎已经回答了这个问题：一个小常数的除法得到了乘法的JIT编辑。 我是手动完成的，现在我一直在以原来的实施方式击败2倍。 基准测试非常简单，只需迭代一组随机的LocalDate并将它们转换为toEpochDay 。 尽管具有随机性，但结果非常一致。 数组的大小是一个参数，我的主要问题是2000到30000之间的大幅减速来自何处 。 应该会有一些减速，因为数据不再适合L1缓存，但两种算法的内存访问完全相同（即，没有，但从数组中获取date ）。 仍然存在的问题是： 如何在迭代数组时，同一函数的两个简单的无内存访问实现的行为会发生变化？ 原始算法的速度比我的慢得多。 我的算法在这里可能不值得复制，它没有文档记录，与原版一样神秘，而且只有一个非常基本的测试 。

如何在不缓存的情况下测量文件读取速度？

我的java程序花了大部分时间来阅读一些文件，我想优化它，例如，通过使用并发，预取， 内存映射文件等。 没有基准测试的优化是没有意义的，所以我进行了基准测试。 但是，在基准测试期间，整个文件内容都缓存在RAM中，与实际运行不同。 因此，基准测试的运行时间要小得多，而且很可能与现实无关。 我需要以某种方式告诉操作系统（Linux）不要缓存文件内容，或者更好地在每次基准测试运行之前清除缓存。 或者可能消耗大部分可用的RAM（32 GB），因此只有很小一部分文件内容适合。如何操作？ 我正在使用卡尺进行基准测试，但在这种情况下我不认为它是必要的（它绝不是微基准测试），我不确定它是个好主意。