Java NIO : Getting Started (Part I)
Reconsidering IO
Friends,
Input Output, IO for short, hardly ever generates the excitement it deserves. Though indispensable, we often prefer not getting our hands dirty with the guts of the subject. It hardly ever appeals to us, and we wonder if its worth our effort. When Java so beautifully abstracts all the messy details, it appears wiser to quickly wrap it all up in few API calls.
We prefer to focus more on improving the processing of the application, to make it smarter by the day. IO naturally gets pushed away from receiving any serious attention. Given our time restraints, our mind just revolts against any idea of prioritizing this particular aspect.
With our concerns(or rather obsession) for process-optimization we often end up with lapses which have serious performance implications.
IO versus Process Time :
No matter how much effort is invested in optimizing the code, all of it may be belittled if the application suffers from IO inefficiencies. Contrary to the "process-optimization will decide it all" perception, which many of us carry, IO is actually a significant determinant in deciding the overall performance of our application. The singular fact that performing IO operations usually takes many times longer than in-memory processing, calls for its careful evaluation. The following analysis will probably elucidate with greater clarity as to how much I/O is crucial in our application. [The figures have been borrowed from the book "JAVA NIO” by Ron Hitchens]
Consider the case(hypothetical) where the in-memory processing of 1 unit of data requires 5 ms and the IO for the same consumes 100 ms. So the throughput of the application turns out to be 9.52 units/second.
[ Formula: (1/(process time + IO time))X 1000].
Now if we manage to decrease the processing time (keeping the IO expense constant) to 1 ms the gain in throughput will be around 3.96%.
However if the IO consumption is reduced to 75 ms (keeping process time fixed at 5 ms) the throughput gain is a whooping 31.25%.
Even at a slight 10% decrease in IO time (90 ms) the gain jumps considerably to 10.53%
The substantial throughput gains are enough to spur us into action and reconsider our IO approach.
Why this neglect?
However its not all our fault that IO takes a back seat! The ignorance stems from an old habit that should have, but did not die with time. In the early days of java JVMs offered little runtime optimization while interpreting the bytecode. They ran slower than their natively compiled counterparts. So there would have not been any specific benefit in working on IO performance. The latency in in-memory operations had diverted the attention from the need to ensure efficiency in IO. That is, the process was too slow and improving IO would not have resulted in any substantial throughput gain. Programmers instinctively remained preoccupied in reducing the processing time.
Nevertheless with time the runtime optimization improved and the processing time dropped. JVMs performed at speeds approaching that of the natively compiled code.IO obviously got pushed to the center stage in determining application performance.
How could Java help?
It was never the case that the OS failed to transmit data fast enough. It was actually the JVM that lagged behind. There was a huge "impedance-mismatch". Let us understand how.
The stream based model of java.io packages treats data byte by byte or character by character. In contrast the OS carts data in large chunks. These chunks need to be broken down by java.io before they can be used. Consequently there is a huge mismatch in the speed with which data is delivered by the OS to java.io and the speed with which java.io processes it further.
This very impedance-mismatch adversely affected the application performance.
Though java.io increases the probability that our application will be kept waiting for I/O, it is not that notorious! There are implementations that have bridged the lacuna to some extent, but still a paradigm shift in the approach was long overdue.
And then Java NIO emerged!
[Reference : "JAVA NIO” by Ron Hitchens]