please skip slashes '/' in my prev. email. I didn't mean any comments there.
Oleksiy Stashok wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>