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
