Re: [mina] JDJ Reader's Awards

[Kaspar Luethi]

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