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.
- Charlie