Java IO compared to NIO
in [Java Programming]
|
From: Arved Sandstrom on 29 Jul 2010 05:35 Daniel Pitts wrote: > On 7/28/2010 2:50 AM, Arved Sandstrom wrote: >> 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. > 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. [ 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. AHS -- I'm not a vegetarian because I love animals. I'm a vegetarian because I hate plants. -- AW Brown
From: John B. Matthews on 29 Jul 2010 22:19 In article <4c513bc0$0$12408$c30e37c6(a)exi-reader.telstra.net>, Esmond Pitt <esmond.pitt(a)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. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Arved Sandstrom on 30 Jul 2010 05:57 John B. Matthews wrote: > In article <4c513bc0$0$12408$c30e37c6(a)exi-reader.telstra.net>, > Esmond Pitt <esmond.pitt(a)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
From: Wayne on 1 Aug 2010 00:23
On 7/30/2010 5:57 AM, Arved Sandstrom wrote: > John B. Matthews wrote: >> In article <4c513bc0$0$12408$c30e37c6(a)exi-reader.telstra.net>, >> Esmond Pitt <esmond.pitt(a)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 > 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 |