Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: NIO not so hot Date: Sun, 18 May 2014 19:09:13 +0200 Lines: 42 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net dPRRdW3s7cPEigmNXUSSpwxPc+P2Zn7nzXMQBD3htAzUmlDSc= Cancel-Lock: sha1:pEOvgGSeERuGkN22G5CTCBuO91o= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:28533 On 18.05.2014 14:12, Robert Klemme wrote: > On 18.05.2014 13:38, Robert Klemme wrote: >> On 18.05.2014 13:38, Robert Klemme wrote: >> >>> https://gist.github.com/rklemme/fad399b5e7cc4d3b6d0c >> >> PS: I just notice some oddity with the ASCII file size which is too >> small. I need to check that. > > Error was duplicate counting chars during creation. This is fixed now. I rearranged execution order a bit to group all read operations on one file and all NIO reads with direct or heap buffer. https://gist.github.com/rklemme/fad399b5e7cc4d3b6d0c#file-output-txt My takeaways: - IO and NIO have roughly same performance for char decoding if done properly. - Adding byte buffering to IO does not help, rather it makes things slower. - Reading into char[] with IO is more efficient than using char buffering. - NIO direct buffers are slower than heap buffers; they are probably best used if the data does not need to reach the Java heap (e.g. when copying a file to another file or a socket). - Best performance with NIO is with a multiple of memory page size (or file system cluster size?). - decoding of pure ASCII in UTF-8 is much more efficient than random UTF-8 data (over 4 times faster per byte than the mixed UTF-8 file). ASCII 0,001525879 us/byte and char UTF 0,006485037 us/byte UTF 0,019073486 us/char Cheers robert