You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2006/01/19 09:11:58 UTC
[mina] JDJ Reader's Awards
Hi all,
I found a class library called 'Unified I/O for Java' is nominated in JDJ
Reader's Awards as a class library. Its web site is:
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?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
Re: [mina] JDJ Reader's Awards
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
2006/1/20, Alessandro Torrisi <al...@eurone.it>:
>
> And what is the impact with Mina ?
I thought there might be some special technique we could adapt. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
Re: [mina] JDJ Reader's Awards
Posted by Kaspar Luethi <ka...@humantools.ch>.
>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 ?
you mean NIO?
no, actually only that the test compares apples with oranges and is flawed.
>And what is the impact with Mina ?
none i think.
kaspar
--
---------------------------------------------
http://www.humantools.com
Re: [mina] JDJ Reader's Awards
Posted by Alessandro Torrisi <al...@eurone.it>.
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
>
Re: [mina] JDJ Reader's Awards
Posted by Kaspar Luethi <ka...@humantools.com>.
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