Hello,
please look at Grizzly's ByteBufferFactory class [1]. As I remember
correctly it's Jeanfrancois's idea... don't allocate small buffers each
time, but allocate the big one, and then "byte" chunks from it.
And just one quick improvement I can propose. Please look at method
write(ByteList):
it does a lot of bad work: copying data, doing that *byte-by-byte*. Is
it possible to make change like that?
/ public int write(ByteList string) throws IOException, BadDescriptorException {
checkWritable();
if (outBuffer.remaining() >= string.realSize) {
outBuffer.put(string.bytes, 0, string.realSize);
/// outBuffer.flip();//
// if(!isSync()) {
flushOutBuffer();
}
// /} else {
/// ByteBuffer buffer = ByteBuffer.wrap(string.bytes,0,string.realSize);
/// flushOutBuffer();
/// flushOutBuffer(buffer);
/// }
return buffer.capacity();
}
/
In that case you will need to reload method flushOutBuffer() with custom
buffer flushOutBuffer(ByteBuffer), but you will avoid data copying.
Think ByteList class also could be improved, but probably it will
require interface changing...
As for ByteBuffer.wrap(byte[])... it can not take much time and should
work fast, as doesn't perform any data copying.
WBR,
Alexey.
[1]
http://fisheye5.cenqua.com/browse/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/ByteBufferFactory.java?r=1.4
charlie hunt wrote:
> Charles Oliver Nutter wrote:
>> Jeanfrancois Arcand wrote:
>>> Hi,
>>>
>>> if peoples are interested to help or share their experience :-)
>>>
>>> Thanks!
>>
>> We're really interested in some help here. You can look at
>>
>> http://jira.codehaus.org/browse/JRUBY-706
>>
>> ...for one sample of work being done to speed up RandomAccessFile
>> usage. However the socket stuff has nobody working on it directly
>> right now, and it appears to be very slow.
>>
>> - Charlie
>
> 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.
>
> I'd love to be jump in help. But, I'm about 2x over booked already :-(
>
> charlie ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>