Prev: byte array
Next: trustAnchors parameter must be non-empty
From: Christian on 29 Mar 2010 08:22
Am 29.03.2010 08:50, schrieb EJP:
> On 29/03/2010 3:15 AM, arun.darra(a)gmail.com wrote:
>>
>> Could someone pls tell me why is the NIO buffering faster than the IO
>> BufferedReader class.
>
> Is it?
>
>> I agree NIO uses FileChannels to access the file.
>
> And ByteBuffers.
>
>> But it in turn uses the FileInputStream.
>
> No it doesn't.
>
>> BufferedReader reader = new BufferedReader(new
>> FileInputStream("File.txt"));
>
> Doesn't compile. Even if you fix that, you are introducing byte-to-char
> overheads here that you don't have in your NIO test. So you are
> comparing apples and oranges.
>
>> Keeping the fact in mind, in both cases the data is being buffered -
>> then how is the NIO method faster than IO Buffer.
>
> I doubt that it is any faster at all, unless you use direct buffers, of
> a much larger size.

I have actually never seen direct ByteBuffers perform better than normal
ByteBuffers... no matter what situation...

From: Roedy Green on 30 Mar 2010 14:15
On Sun, 28 Mar 2010 09:15:35 -0700 (PDT), "arun.darra(a)gmail.com"
<arun.darra(a)gmail.com> wrote, quoted or indirectly quoted someone who
said :

>
>Could someone pls tell me why is the NIO buffering faster than the IO
>BufferedReader class.

Except for the Mapped stuff, both use the same physical i/o.

nio offers a few benefits:

1. easier multithreading.

2. you can pluck a few bytes out of the buffer. With DataInputStream,
typically you read and process every byte. (Granted you can skip with
BufferedInputStream too.)

I asked myself the same question and did not come up with a
satisfactory answer. It seemed the added complexity would not provide
that much payback except for the Mapped stuff. Some benchmarks are in
order.

--
Roedy Green Canadian Mind Products
http://mindprod.com

If you tell a computer the same fact in more than one place, unless you have an automated mechanism to ensure they stay in sync, the versions of the fact will eventually get out of sync.
From: Christian on 31 Mar 2010 05:21
Am 30.03.2010 20:15, schrieb Roedy Green:
> On Sun, 28 Mar 2010 09:15:35 -0700 (PDT), "arun.darra(a)gmail.com"
> <arun.darra(a)gmail.com> wrote, quoted or indirectly quoted someone who
> said :
>
>>
>> Could someone pls tell me why is the NIO buffering faster than the IO
>> BufferedReader class.
>
> Except for the Mapped stuff, both use the same physical i/o.
>
> nio offers a few benefits:
>
> 1. easier multithreading.
>
> 2. you can pluck a few bytes out of the buffer. With DataInputStream,
> typically you read and process every byte. (Granted you can skip with
> BufferedInputStream too.)
>
> I asked myself the same question and did not come up with a
> satisfactory answer. It seemed the added complexity would not provide
> that much payback except for the Mapped stuff. Some benchmarks are in
> order.
>

Isn't the main Payback of nio that you can use it non blocking mode...
You certainly don't want to have as many threads open as connections in
a setting where several hundred parallel connections are possible...

Christian
From: Arne Vajhøj on 31 Mar 2010 20:09
On 31-03-2010 05:21, Christian wrote:
> Isn't the main Payback of nio that you can use it non blocking mode...
> You certainly don't want to have as many threads open as connections in
> a setting where several hundred parallel connections are possible...

On high-end HW you can support hundreds of threads.

Go to thousands and something else is necessary.

Arne

From: EJP on 1 Apr 2010 02:35
On 31/03/2010 5:15 AM, Roedy Green wrote:
> Except for the Mapped stuff, both use the same physical i/o.

But with a ByteBuffer and FileChannel there is less implied data copying
than with e.g. a BufferedReader/InputStreamReader/FileInputStream.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: byte array
Next: trustAnchors parameter must be non-empty