Hi,
Does anyone know what the performance difference is between Java NIO vs DotNet IO performance.
Reading this question, it seems that standard Java-IO and DotNet-IO have very similar IO performance.
What is interesting to me is that the Java guys state that mass file copying, file server based operations...etc should be a lot quicker because of access to the file channels etc in Java-NIO.
Is it possible that java.nio performance is better than DotNet System.IO.
Thanks.
I actually can not answer this, but I can think freely...
.. both Java-File-IO and .Net should use underlaying OS operations for file access, and file access is always IO bound and not CPU bound. Meaning that disks are slower then CPU and memory.
What this would mean is that Java-File-IO and .Net should be the same in terms of performance.
When it comes to Socket communication Java did a horrible work, and actually just ignore the Posix standard and didn't use OS call 'select'. This was fixed in Java NIO with the introduction of "channels" that is nothing more then actually supporting the underlaying architecture. Before you needed to allocated a thread for every socket you was reading on, horrible wastage of resources.
Since .Net is newer then Java, I would believe that they never fell into this trap and added support for this from the start.. But I haven't used .Net so I can tell, I can not guess.
Regarding Socket communication in both cases Java-NIO and .Net System.IO, both should be network bound before they become CPU bound anyhow. So I don't think one would be faster then the other.
as far as file copying, there shouldn't be significant differences, no matter what platform or api you are using. the bottle neck is the disk spinning and head seeking of the hard drive. *
what needs to happen, is to move content of harddisk to some memory, then write the memory to harddisk. with traditional java io stream, there will be extra memory copies. still that's not significant waste compared to disk speed.
this can be easily verified, FileChannel.transferTo/From cannot beat old way of input-output stream copying by much.
(*) of course, there are much faster disks now, but as long as we define disk as the next slower storage after memory, the argument holds.
(**)we could call a virtual disk a disk, which actually resides in main memory. then memory copy is the bottle neck, and the argument doesn't hold any more.