Charles Oliver Nutter wrote:
> charlie hunt wrote:
>> You might consider trying a MappedByteBuffer with your FileChannel if
>> you have the address space to work with and/or tend to be looking at
>> the same file most of the time along with having evidence you are
>> reading and writing to that file an awful lot.
>>
>> I'd also try to avoid HeapByteBuffer which is what's returned by
>> ByteBuffer.allocate().
>>
>> If you find you have all of your data in byte[]'s, then you may be
>> better off using HeapByteBuffer. However, note that every time you
>> send a HeapByteBuffer to a FileChannel, (or a SocketChannel), and
>> when your read into a HeapByteBuffer from a FileChannel (or a
>> SocketChannel), you are copying bytes between a byte[] and native space.
>>
>> I've never been a big fan of copying data and avoid it whenever
>> possible. However, if you are manipulating your data in byte[]'s,
>> then you'll ultimately end up copying the data anyway. In such a
>> case, try to minimize the number of times you actually invoke the
>> operation to copy data from a byte[] or HeapByteBuffer.
>
> So is it reasonable to say that NIO would serve us best
> (performance-wise) only in cases where we could leave the data on the
> native side straight through? Does NIO gain us anything over
> plain-old-buffering if we're constructing a lot of byte sequences in
> little pieces?
>
> In general we've seen that a second version of a buffered
> RandomAccessFile performs a bit better than the NIO-based version. But
> it's certainly possible we can improve the NIO version if there's
> something specific that would help it.
The size of the (Direct)ByteBuffer that's used to read or write the data
will be the biggest contributor to improving read / write performance to
/ from the FileChannel.
The size of the (Direct)ByteBuffer is gonna be somewhat similar to the
notion of the size of a Buffered[Input|Output]Stream you'd use with a
File[Input|Output]Stream. You can write a simple micro-benchmark to
convince yourself of that.
In order to realize the full potential of NIO based reading / writing
you'd need to keep the data in the DirectByteBuffer when reading and
writing directly to a DirectByteBuffer on the output side.
Another place where you can potentially get more from NIO is in scatter
reads and scatter writes. However, I haven't done any work in this area
as of yet. But, from what I have many developers have struggled to
realize gains.
If you're finding using pre-NIO buffered stream approach meets you
performance needs, then there's nothing wrong with staying with it. To
keep your options open you could always hide the implementation behind
your APIs should you find some day that NIO beats your buffered stream
implementation.
hths,
charlie ...
>
> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>