Can I make this program that extracts text data from a file (size in MBs) even better performance-wise? I need to reduce the execution time.
import java.io.*;
public class ReadData {
public static void main(String[] args) {
FileReader input = null;
BufferedReader br = null;
try {
input = new FileReader("C:/Projects/Test/HPCamDrv.log");
br = new BufferedReader(input);
String str;
while ((str = br.readLine()) != null) {
System.out.println(str);
}
}
catch (IOException e) {
e.printStackTrace();
}
finally {
try {
input.close();
br.close();
}
catch (IOException x) {
x.printStackTrace();
}
}
}
}
3 Answers 3
It's a pretty small and straight-forward program and not really much to improve on. ChrisWue also brings up the good point that printing to stdout
for every line is costly but if you need to print it to stdout
there's not much to do about it.
But one thing you can actually do is implement Java's try-with resources which will ensure your resources are closed at the end of the statement, so you can get rid of all your .close()
calls and your finally
block.
Your question asks about data extraction, but the code actually just prints the file to System.out
with possible Carriage return/Newline translation. Frankly, you haven't asked a very good question (it doesn't do what you claim, and it lacks specific details about how poor your performance is or how you measured it), but there is some code to be reviewed anyway.
Your exception handling is wrong. What happens if new FileReader(...)
throws an exception?
There is some hidden work being done that you may not be aware of.
- As I alluded to above,
BufferedReader.readLine()
accepts either Carriage return, Newline, or some combination of the two as a line termination marker. Then,System.out.println()
will print each line, using the Java default line termination character. If you don't need this normalization of the line termination, don't call.readLine()
. Just repeatedly read to achar[]
buffer and write it out. Then you also wouldn't be creating aString
for each line. FileReader
might also be doing some extraneous work. It creates anInputStreamReader
that translates bytes into chars using the system default character encoding. Assuming you don't care about such transcoding, you could work withbyte[]
arrays instead.- If you just want to funnel data from a source to a sink as efficiently as possible,
java.nio.file.Files.copy()
is probably your best bet.
That said, the code you wrote is pretty standard and is fast enough for most purposes, and you usually don't need to resort to the hacks I mentioned above. If you're seeing a performance problem, it's probably because your System.out
is attached to your console, and console output is slow. (Sometimes surprisingly so!) Try redirecting your System.out
to /dev/null
or NUL:
to measure your input and output bottlenecks separately.
If you must do System.out.println()
then build everything in a new StringBuilder
first so that your console io comes way down. Really, you need to decide what it is you're trying to actually accomplish. This code snippet looks like a homework assignment not a real attempt at a professional solution.
To also balance with memory considerations, use a modulo counter with reset on the buffer
try {
int count = 0;
StringBuilder builder = new StringBuilder();
input = new FileReader("C:/Projects/Test/HPCamDrv.log");
br = new BufferedReader(input);
String str;
while ((str = br.readLine()) != null) {
builder.append(str);
if(count++ % 100) {
System.out.println(builder);
builder = new StringBuilder(); // or builder.setLength(0);
}
}
}
cat
and on Windowstype
which do exactly the same thing. \$\endgroup\$