Excuse me I didn't understand... > Using java.nio: 0 > Combine Unified I/O with java.nio: 844 this means Java IO is much more performant than UIO ? And what is the impact with Mina ? Let me knwo about this, thx very much Alex On 19/gen/06, at 18:22, Kaspar Luethi wrote: > hi trustin > > i hope you were successful finding a new job. > >> https://uio.dev.java.net/ >> It claims that it performs much better than plain java.io and >> java.nio file >> I/O class libraries. But there's no much information on >> implementation >> details we could learn from the author. Anyone who knows about UIO? > > no, but i just had a little look at it. > wouldn't it be silly to claim a better performance than pure nio? > it seemed > to me, so i looked in the perfomance-test code for flaws. > > after a small change i get different results: > > running IOTest.java: > (...) > Using java.nio: 0 > Combine Unified I/O with java.nio: 844 > > :) > > > it looks unfair, the nio-only test has to recreate its bytebuffer > every time > > for(int i = 0; i < 100; i++) { > byteBuffer.clear(); > for(int j = 0; j < intArray.length; j++) { > byteBuffer.putInt(intArray[j]); > } > channel.write(byteBuffer); > } > > so i changed it to > > byteBuffer.clear(); > for(int j = 0; j < intArray.length; j++) { > byteBuffer.putInt(intArray[j]); > } > > for(int i = 0; i < 100; i++) { > channel.write(byteBuffer); > } > > (when sending to different channels, we would have used the famous > byteBuffer.duplicate() here, using it takes 16ms instead 0ms in > this test. > so there is some cost in duplicate() but much less than copying). > > i might have missed some of the authors intentions here, but in > "writeComby()" he doesn't perform an action similar to the int copying > in writeNio(). "RandomAccessRO.readFully()" in "writeComby()" uses > System.arraycopy. > > the library itself looks like to be designed for fileIO and specially > image file access. but the performance claim looks pretty broken. > > kaspar >