Forum Project: Most common misunderstandings people have

Question

Hi all
I know this is a holiday weekend and all so there might be fewer people using the java boards. But I thought it might be fun to colaboratively put together a little list of common misconceptions that people have in the java world. I am starting this of with a common misconception about I/O
=======
Common misconception: Using a BufferedInputStream or a BufferedReader will make all reading faster
Answer: Using a buffer will only make your reads faster if you are doing inefficient reading, meaning for example that rather than load a whole file in one big chunk you are reading line by line.

Answer 1

tjacobs01 wrote:
1. How do you know your buffer is going to be big enough?I use the same buffer size on the client. Which is an advantage of a closed system. (Actually its a bit more complicated, the client and server exchange the maximum message size on connection and take the highest of these two values)
2. Assuming that once you've done a read, you copy the data somewhere else and effectively flush the buffer / start at 0 again, you have to do a whole bunch of extra work if the buffer is completely filled by the incoming data and there is no more waiting.I have a large buffer like 256KB or 1 MB so a message always fits into the buffer.
What I do is have the size of the message at the start and a minimum message size of 256 bytes.
So I read 256 bytes which is often all I need, but if the length is longer I read the full length. This gives me one message with no need for copying. (And I use DirectByteBuffer)
It also gives me the message in a single read.
Maybe I just don't understand your solution entirely. It goes back to question 1. That wouldn't be surprising. I make a few assumptions. :)
The other thing is that the call to available() in socket reading effectively costs you nothing - the bottleneck is the rate at which data is coming in through the socket.I find the number of calls you make also creates overhead...
BTW: My solution is for server to server communications so I can assume there is a small number (<100) of controlled connections but there is a high volume of data which requires a low latency.
The solution (with custom serialization/RMI) can perform RMI calls as low at 20 us. (on loopback) and 110 us on a LAN. And send over 100,000 message per second over a single channel.
The custom serialization support serialization to/from DirectByteBuffer.