Java IO compared to NIO

[John B. Matthews]

This presentation compares Java synchronous (java.io.*) to asynchronous
(java.nio.*) I/O in a high volume SMTP application, finding a measurable
benefit for the former with modern threading libraries and multi-core
machines.

<http://www.mailinator.com/tymaPaulMultithreaded.pdf>

Some discussion may be found here:

<http://developers.slashdot.org/story/10/07/27/1925209>

The few times the choice has come up, we implemented synchronous I/O,
profiled it, found it met the requirements and declared victory. Lacking
much experience in this area, I'd welcome critical comments.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Arved Sandstrom]

John B. Matthews wrote:
> This presentation compares Java synchronous (java.io.*) to asynchronous
> (java.nio.*) I/O in a high volume SMTP application, finding a measurable
> benefit for the former with modern threading libraries and multi-core
> machines.
>
> <http://www.mailinator.com/tymaPaulMultithreaded.pdf>
>
> Some discussion may be found here:
>
> <http://developers.slashdot.org/story/10/07/27/1925209>
>
> The few times the choice has come up, we implemented synchronous I/O,
> profiled it, found it met the requirements and declared victory. Lacking
> much experience in this area, I'd welcome critical comments.
>

Yeah, I was just reading about this Paul Tyma discovery myself. I'm not
prepared to comment on it other than to say that the presented arguments
are plausible. I'll also note that the main argument has been made
before - it's not a stunning new revelation.

On a related note, if "old" I/O meets your requirements then what more
do you need? :-) I've been generally content with "old" I/O in most
situations.

And as an aside, one thing I noticed with NIO when it came out,
specifically concerning use of the Selector, was that the new API
promoted a fair bit of black-box copy-paste programming. Admittedly I
have only a small set of observations, but quite frankly the only time I
ran across a group of people that thoroughly understood their NIO code
was when their original code had been C code and they were using the
select() call there. It might perhaps be more accurate to say that NIO
did not *promote* this copy-paste programming; it simply perpetuated it
- it wasn't easier for the average programmer to understand than "old" I/O.

AHS

--
I'm not a vegetarian because I love animals. I'm a vegetarian because I
hate plants.
-- AW Brown

[Daniel Pitts]

It was never meant to be easier, it was meant to reduce the number of
threads required for handling multiple "streams" of data. It is actually
far more complicated to get correct, often requiring a state machine.
For a single stream, I suspect there is no speed benefit.

As far as efficiency goes, my guess is that there is a sweet-spot for
the number of streams-per-thread which outperforms regular IO. This
sweet-spot would depend on many factors, including overall system-load,
threading implementation, low-level select implementation, and stream
throughput.

Just a thought.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

[John B. Matthews]

In article <%6%3o.30711$xZ2....@newsfe07.iad>,
Daniel Pitts <newsgroup....@virtualinfinity.net> wrote:

Thanks, both, for commenting on this. I also found this thread helpful:

<http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/dd8005f33b883d02>

[Esmond Pitt]

On 29/07/2010 2:30 PM, John B. Matthews wrote:
> Thanks, both, for commenting on this. I also found this thread helpful:
>
> <http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/dd8005f33b883d02>

You should also have a look at 'Taming the NIO Circus' at
forums.sun.com: http://forums.sun.com/thread.jspa?threadID=459338&start=0

[Arved Sandstrom]

[ SNIP ]

Your observations are true. If I were to make my point another way, it
would be that it's human nature to equate "more capable" with "easier to
use". When Java NIO appeared in 1.4 it wasn't advertised as being
easier, but it was certainly advertised - frequently - as "fixing" Java
I/O. No small number of Java programmers, the majority of them
relatively inexperienced (and I mean inexperienced both in the language
and in matters I/O), took "fixed" to mean "prefer NIO to 'old'
I/O"...which wasn't necessarily the right choice. Because, as you point
out, it's often more complicated to get NIO right.

[John B. Matthews]

In article <4c513bc0$0$12408$c30e...@exi-reader.telstra.net>,
Esmond Pitt <esmon...@bigpond.com> wrote:

Thank you for this link; the code is exemplary: both commendable and
cautionary. It highlights Daniel Pitts' point that NIO tends to be more
complex. Mindful of AHS's observation that the inexperienced tend to
prefer NIO without good reason, I am always looking for heuristics that
might inform the right choice.

[Arved Sandstrom]

John B. Matthews wrote:
> In article <4c513bc0$0$12408$c30e...@exi-reader.telstra.net>,
> Esmond Pitt <esmon...@bigpond.com> wrote:
>
>> On 29/07/2010 2:30 PM, John B. Matthews wrote:
>>> Thanks, both, for commenting on this. I also found this thread helpful:
>>>
>>> <http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/dd8005f33b883d02>
>> You should also have a look at 'Taming the NIO Circus' at forums.sun.com:
>> http://forums.sun.com/thread.jspa?threadID=459338&start=0
>
> Thank you for this link; the code is exemplary: both commendable and
> cautionary. It highlights Daniel Pitts' point that NIO tends to be more
> complex. Mindful of AHS's observation that the inexperienced tend to
> prefer NIO without good reason, I am always looking for heuristics that
> might inform the right choice.
>

NIO is a large API, as you know. If we are talking specifically about
using Selectors and Channels in a Java project, and YMMV here, I've
found it to be a useful exercise to work (or have worked) a problem in C
using select (or poll/epoll, depends on what you've got available).

I'm not going to make this a hard recommendation, but speaking only for
myself I've found that my comfort level with Java I/O, both "old" and
"new", has been enhanced by tackling all of the equivalent situations in
C (usually) over the decades. By doing so one tends to have a better
understanding, for I/O specifically, of what Java is doing under the
hood on your system.

AHS

--
Give a man a fish, and he can eat for a day. But teach a man how to
fish, and he'll be dead of mercury poisoning inside of three years.
--Charles Haas

[Wayne]

The Sun (Oracle) JRE uses NIO to implement java.io. I'd bet that for
90% of the cases the performance of java.io routines should be the same
as for using raw java.nio classes and routines. I think the reason that
using NIO appears worse some of the time may be because the NIO API
is harder for many programmers to use to full advantage. (OT: I worry
about the new date and time API for the same reason.)

I agree with Arved that studying the implementation details of the *IO
libraries would enhance a programmer's ability to choose the correct API
to fit a given situation, and to use it to best advantage. But I think it
may be a mistake to design such complex APIs that this kind of investment
in time and effort, to master just a small part of the standard library,
is necessary. "Feature Creep" will be the death of Java.

--
Wayne

[Esmond Pitt]

On 1/08/2010 2:23 PM, Wayne wrote:
> The Sun (Oracle) JRE uses NIO to implement java.io.

It uses *some of* NIO to implement java.io. It doesn't use for example
ByteBuffers, or it didn't last time I looked. It would be more accurate
to say that they both use a thin layer over the Sockets API.