gpt4 book ai didi

java - 为什么 BufferedReader read() 比 readLine() 慢得多?

转载 作者:IT老高 更新时间:2023-10-28 20:47:08 25 4
gpt4 key购买 nike

我需要一次读取一个文件,我正在使用 BufferedReader 中的 read() 方法。 *

我发现 read()readLine() 慢大约 10 倍。这是预期的吗?还是我做错了什么?

这是 Java 7 的基准测试。输入的测试文件有大约 500 万行和 2.54 亿个字符(~242 MB)**:

read() 方法读取所有字符大约需要 7000 毫秒:

@Test
public void testRead() throws IOException, UnindexableFastaFileException{

BufferedReader fa= new BufferedReader(new FileReader(new File("chr1.fa")));

long t0= System.currentTimeMillis();
int c;
while( (c = fa.read()) != -1 ){
//
}
long t1= System.currentTimeMillis();
System.err.println(t1-t0); // ~ 7000 ms

}

readLine() 方法只需要大约 700 毫秒:

@Test
public void testReadLine() throws IOException{

BufferedReader fa= new BufferedReader(new FileReader(new File("chr1.fa")));

String line;
long t0= System.currentTimeMillis();
while( (line = fa.readLine()) != null ){
//
}
long t1= System.currentTimeMillis();
System.err.println(t1-t0); // ~ 700 ms
}

* 实用目的:我需要知道每一行的长度,包括换行符(\n or \r\n ) 以及剥离它们后的线长。我还需要知道一行是否以 > 字符开头。对于给定的文件,这仅在程序开始时执行一次。由于 BufferedReader.readLine() 不返回 EOL 字符,因此我使用 read() 方法。如果有更好的方法,请说。

** gzip压缩文件在这里http://hgdownload.cse.ucsc.edu/goldenpath/hg19/chromosomes/chr1.fa.gz .对于那些可能想知道的人,我正在编写一个类来索引 fasta 文件。

最佳答案

分析性能时,重要的是在开始之前有一个有效的基准。因此,让我们从一个简单的 JMH 基准测试开始,它显示了我们在热身后的预期性能。

我们必须考虑的一件事是,由于现代操作系统喜欢缓存定期访问的文件数据,我们需要一些方法来清除测试之间的缓存。在 Windows 上有一个小实用程序 that does just this - 在 Linux 上,你应该可以通过在某处写入一些伪文件来做到这一点。

代码如下:

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Mode;

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

@BenchmarkMode(Mode.AverageTime)
@Fork(1)
public class IoPerformanceBenchmark {
private static final String FILE_PATH = "test.fa";

@Benchmark
public int readTest() throws IOException, InterruptedException {
clearFileCaches();
int result = 0;
try (BufferedReader reader = new BufferedReader(new FileReader(FILE_PATH))) {
int value;
while ((value = reader.read()) != -1) {
result += value;
}
}
return result;
}

@Benchmark
public int readLineTest() throws IOException, InterruptedException {
clearFileCaches();
int result = 0;
try (BufferedReader reader = new BufferedReader(new FileReader(FILE_PATH))) {
String line;
while ((line = reader.readLine()) != null) {
result += line.chars().sum();
}
}
return result;
}

private void clearFileCaches() throws IOException, InterruptedException {
ProcessBuilder pb = new ProcessBuilder("EmptyStandbyList.exe", "standbylist");
pb.inheritIO();
pb.start().waitFor();
}
}

如果我们用

运行它
chcp 65001 # set codepage to utf-8
mvn clean install; java "-Dfile.encoding=UTF-8" -server -jar .\target\benchmarks.jar

我们得到以下结果(为我清除缓存需要大约 2 秒,我在 HDD 上运行它,所以它比你慢很多):

Benchmark                            Mode  Cnt  Score   Error  Units
IoPerformanceBenchmark.readLineTest avgt 20 3.749 ± 0.039 s/op
IoPerformanceBenchmark.readTest avgt 20 3.745 ± 0.023 s/op

惊喜!正如预期的那样,在 JVM 进入稳定模式之后,这里根本没有性能差异。但是 readCharTest 方法中有一个异常值:

# Warmup Iteration   1: 6.186 s/op
# Warmup Iteration 2: 3.744 s/op

这正是您所看到的问题。我能想到的最可能的原因是 OSR 在这里做得不好,或者 JIT 运行得太晚,无法在第一次迭代中产生影响。

根据您的用例,这可能是一个大问题或可以忽略不计(如果您正在阅读一千个文件,这无关紧要,如果您只阅读一个,这是一个问题)。

解决这样的问题并不容易,也没有通用的解决方案,尽管有一些方法可以解决这个问题。一个简单的测试,看看我们是否走在正确的轨道上,是使用 -Xcomp 选项运行代码,该选项强制 HotSpot 在第一次调用时编译每个方法。事实上,这样做会导致第一次调用时的大延迟消失:

# Warmup Iteration   1: 3.965 s/op
# Warmup Iteration 2: 3.753 s/op

可能的解决方案

现在我们已经很好地了解了实际问题是什么(我的猜测仍然是所有这些锁既没有被合并也没有使用有效的偏向锁实现),解决方案相当简单明了:减少函数调用的次数(所以是的,我们可以在没有上述所有内容的情况下得出这个解决方案,但是很好地掌握问题总是很好的,并且可能有一个不涉及更改太多代码的解决方案。

以下代码的运行速度始终比其他两个中的任何一个都快 - 您可以使用数组大小​​,但它出奇地不重要(可能是因为与其他方法相反 read(char[]) 没有必须获得锁,因此每次调用的成本较低)。

private static final int BUFFER_SIZE = 256;
private char[] arr = new char[BUFFER_SIZE];

@Benchmark
public int readArrayTest() throws IOException, InterruptedException {
clearFileCaches();
int result = 0;
try (BufferedReader reader = new BufferedReader(new FileReader(FILE_PATH))) {
int charsRead;
while ((charsRead = reader.read(arr)) != -1) {
for (int i = 0; i < charsRead; i++) {
result += arr[i];
}
}
}
return result;
}

这很可能在性能方面已经足够好,但如果您想进一步提高性能,请使用 file mapping可能(在这种情况下不会指望太大的改进,但如果您知道您的文本始终是 ASCII,您可以进行一些进一步的优化)进一步提高性能。

关于java - 为什么 BufferedReader read() 比 readLine() 慢得多?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41324192/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com