Java: Efficiency of the readLine method of the BufferedReader and possible alternatives

Question

We are working to reduce the latency and increase the performance of a process written in Java that consumes data (xml strings) from a socket via the readLine() method of the BufferedReader class. The data is delimited by the end of line separater (\n), and each line can be of a variable length (6KBits - 32KBits). Our code looks like:

Socket sock = connection;
InputStream in = sock.getInputStream();
BufferedReader inputReader = new BufferedReader(new InputStreamReader(in));
...
do 
{
   String input = inputReader.readLine();
   // Executor call to parse the input thread in a seperate thread
}while(true)

So I have a couple of questions:

• Will the inputReader.readLine() method return as soon as it hits the \n character or will it wait till the buffer is full?
• Is there a faster of picking up data from the socket than using a BufferedReader?
• What happens when the size of the input string is smaller than the size of the Socket's receive buffer?
• What happens when the size of the input string is bigger than the size of the Socket's receive buffer?

I am getting to grips (slowly) with Java's IO libraries, so any pointers are much appreciated.

Thank you!

Answer 1

Will the inputReader.readLine() method return as soon as it hits the \n character or will it wait till the buffer is full?

• It will return as soon as it gets a newline.

Is there a faster of picking up data from the socket than using a BufferedReader?

• BufferedReader entails some copying of the data. You could try the NIO apis, which can avoid copying, but you might want to profile before spending any time on this to see if it really is the I/O that is the bottleneck. A simpler quick fix is to add a BufferedInputStream around the socket, so that each read is not hitting the socket (It's not clear if InputStreamReader does any buffering itself.) e.g.

  new BufferedReader(new InputStreamReader(new BufferedInputStream(in)))

What happens when the size of the input string is smaller than the size of the Socket's receive buffer?

• The BufferedReader will fetch all the data availalbe. It will then scan this data to look for the newline. The result is that subsequent reads may already have the data in the BufferedReader.

What happens when the size of the input string is bigger than the size of the Socket's receive buffer?

• The bufferedReader will read what is in the recieve buffer, and as there is no newline or the end of stream is reached, it will continue to read data from the socket until it finds EOF or a newline. Subsequent reads may block until more data becomes available.

To sum up, BufferedReader blocks only when absolutely necessary.

Answer 2

One of the advantages of the BufferedReader is that it provides a layer of separation (the buffer) between the input methods (read, readLine, etc.) you use and the actual socket reads, so you don't have to worry about all the cases like "most of the line is in the buffer, but you need to read another buffer to get the \n" etc.

Have you done performance measurement that indicates that using a BufferedReader is a performance issue for your application? If not, I would suggest that you start by choosing an input method which provides the functionality you want (line-based input terminated by \n's, from the sound of it), and worry about if there's a "faster" way to do it only if you find the input method is a bottleneck.

If line-based input is really what you're after, you're going to end up using some kind of buffer like BufferedReader does, so why re-invent this wheel?