为什么我在BufferedReader中使用*更大的*缓冲区获得更差*性能？

Question

我得到了奇怪的结果当我改变缓冲区的大小时，我无法从BufferedReader解释。

我强烈期望随着我增加缓冲区的大小，性能会逐渐增加，收益递减设置得相当快，之后性能会或多或少持平。但似乎只有非常适度的缓冲区大小后，增加缓冲区的大小会使其变慢。

这是一个极小的例子。它所做的只是通过文本文件运行，并计算行的长度之和。

public int traverseFile(int bufSize) throws IOException {
    BufferedReader reader = new BufferedReader(new FileReader("words16"), bufSize*1024);
    String line;
    int total=0;
    while ((line=reader.readLine())!=null)
        total+=line.length();
    reader.close();
    return total;
}

我尝试使用各种缓冲区大小对此进行基准测试，结果相当奇怪。高达约256KB，性能提升;在那之后，它变得更糟。我想知道是否只是分配缓冲区所需的时间，所以我尝试添加一些内容以使其始终分配相同的内存总量（参见下面的第二行）：

public int traverseFile(int bufSize) throws IOException {
    byte[] pad = new byte[(65536-bufSize)*1024];
    BufferedReader reader = new BufferedReader(new FileReader("words16"), bufSize*1024);
    String line;
    int total=0;
    while ((line=reader.readLine())!=null)
        total+=line.length();
    reader.close();
    return total;
}

这没有任何可能性。我仍在两台不同的机器上得到相同的结果。以下是完整的结果：

Benchmark                                        Mode  Samples    Score   Error  Units
j.t.BufferSizeBenchmark.traverse_test1_4K        avgt      100  363.987 ± 1.901  ms/op
j.t.BufferSizeBenchmark.traverse_test2_16K       avgt      100  356.551 ± 0.330  ms/op
j.t.BufferSizeBenchmark.traverse_test3_64K       avgt      100  353.462 ± 0.557  ms/op
j.t.BufferSizeBenchmark.traverse_test4_256K      avgt      100  350.822 ± 0.562  ms/op
j.t.BufferSizeBenchmark.traverse_test5_1024K     avgt      100  356.949 ± 0.338  ms/op
j.t.BufferSizeBenchmark.traverse_test6_4096K     avgt      100  358.377 ± 0.388  ms/op
j.t.BufferSizeBenchmark.traverse_test7_16384K    avgt      100  367.890 ± 0.393  ms/op
j.t.BufferSizeBenchmark.traverse_test8_65536K    avgt      100  363.271 ± 0.228  ms/op

正如您所看到的，最佳点是大约256KB。差异并不大，但肯定是可以衡量的。

我只能想到这可能与内存缓存有关。是因为写入的RAM是否远离正在读取的RAM？但如果它是一个循环缓冲区，我甚至不确定它是真的：正在编写的内容将落后于正在阅读的内容。

words16文件是80MB，因此我无法在此处发布，但它是Fedora的标准/usr/share/dict/words文件，是16倍。如有必要，我可以找到发布链接的方法。

以下是基准代码：

@OutputTimeUnit(TimeUnit.MILLISECONDS)
@BenchmarkMode(Mode.AverageTime)
@OperationsPerInvocation(1)
@Warmup(iterations = 30, time = 100, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 100, time = 10000, timeUnit = TimeUnit.MILLISECONDS)
@State(Scope.Thread)
@Threads(1)
@Fork(1)
public class BufferSizeBenchmark {

    public int traverseFile(int bufSize) throws IOException {
        byte[] pad = new byte[(65536-bufSize)*1024];
        BufferedReader reader = new BufferedReader(new FileReader("words16"), bufSize*1024);
        String line;
        int total=0;
        while ((line=reader.readLine())!=null)
            total+=line.length();
        reader.close();
        return total;
    }

    @Benchmark
    public int traverse_test1_4K() throws IOException {
        return traverseFile(4);
    }

    @Benchmark
    public int traverse_test2_16K() throws IOException {
        return traverseFile(16);
    }

    @Benchmark
    public int traverse_test3_64K() throws IOException {
        return traverseFile(64);
    }

    @Benchmark
    public int traverse_test4_256K() throws IOException {
        return traverseFile(256);
    }

    @Benchmark
    public int traverse_test5_1024K() throws IOException {
        return traverseFile(1024);
    }

    @Benchmark
    public int traverse_test6_4096K() throws IOException {
        return traverseFile(4096);
    }

    @Benchmark
    public int traverse_test7_16384K() throws IOException {
        return traverseFile(16384);
    }

    @Benchmark
    public int traverse_test8_65536K() throws IOException {
        return traverseFile(65536);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(
                        ".*" + BufferSizeBenchmark.class.getSimpleName() + ".*")
                .forks(1).build();

        new Runner(opt).run();
    }

}

为什么在增加缓冲区大小时性能会下降？

Answer 1

这很可能是缓存行大小的影响。由于缓存使用LRU驱逐策略使用太大的缓冲区导致您已经写入“开始”的内容。在你有机会阅读它之前要被驱逐的缓冲区。

Answer 2

256k是典型的CPU缓存大小！你测试过什么类型的CPU？

所以会发生的情况是：如果您读取256k或更小的块，则当读取访问缓冲区时，写入缓冲区的内容仍然在CPU缓存中。如果你有超过256k的块，那么读取的最后256k是在CPU缓存中，所以当从头开始读取时，必须从主存中检索内容。

第二个问题是缓冲区分配。填充缓冲区的技巧很聪明，但并没有真正平均分配成本。这样做的原因是，分配的实际成本不是内存的保留，而是清除它。此外，OS可以推迟到真实存储器中映射到它首次被访问的时间。但是你永远不会访问填充缓冲区。