question about performance of FrameDecoder and ChannelBuffer

[Trustin Lee]

Hi Christian,

Now I see the point.  The second approach looks better to me.

On the other hand, you might want to try ReplayingDecoder, which is
useful when you implement a complicated decoder which doesn't have an
explicit delimiter.  It doesn't have enough documentation at this
moment, but I think you can give it a try after reading its Javadoc and
the ReplayingDecoder implementations that is provided with Netty:

  * ReplayingDecoder Javadoc - http://tinyurl.com/5tkwnw
  * ReplayingDecoder Source - http://tinyurl.com/6ow6pu
  * CompatibleObjectInputStream - http://tinyurl.com/6xt3ab

With ReplayingDecoder, you should even be able to use an existing SAX
parser.

HTH,
Trustin

On Sat, Nov 22, 2008 at 05:18:32AM +0900, Christian Migowski wrote:
> Hello,
> 
> Jan: of course, if I could use my own protocol, i would have also
> implemented something with fixed delimiters, but most of the time
> you'll have to work with already defined protocols, and the one I am
> going to implement isn't very "network-implementation-friendly".
> 
> Trustin: you misunderstood me a little bit. To make it clear, I was
> asking for your opinion what would perform better in
> FrameDecoder.decode(...)
> 
> 	int start = buffer.readerIndex();
> 	byte[] msgbuf = new byte[buffer.readableBytes()];
> 	buffer.readBytes(msgbuf);
> (and thus reading potentially many messages that are in the
> channelbuffer just for extracting one)
> 
> vs.
> 	byte[] msgbuf = new byte[512*i];
> 	buffer.readBytes(msgbuf);
> (i being the cound decode is called when a message could not be found
> in the byte array)
> 
> 
> But thanks for pointing me to look into the FrameDecoder sourcecode, I
> think now way two is more likely to be better since not so many bytes
> need to be copied.
> 
> 
> christian
> 
> On Fri, Nov 21, 2008 at 8:31 AM, Trustin Lee <tlee at redhat.com> wrote:
>> Hi Christian,
>>
>> On Thu, Nov 20, 2008 at 06:38:35PM +0900, Christian Migowski wrote:
>>> Hi,
>>>
>>> I want to implement a protocol decoder with Netty for a protocol that
>>> hasn't fixed length nor fixed delimiter delimited messages (until I
>>> look at it that is: XML fragments).
>>> I think I am going to use the FrameDecoder for this, what do you think
>>> is the most efficient approach with Netty:
>>> - in the decode(...) method, should I:
>>>
>>> (a) read all readableBytes() from the ChannelBuffer, try to find the message
>>> disadvantage: I may (quite certainly) read much more than one message
>>> from the Buffer, but for the sake of simple processing I want to
>>> decode only one message at a time; i.e. I read messages multiple times
>>> from the ChannelBuffer until they are "first"
>>
>> This is perhaps what FrameDecoder is already doing?  You might want to
>> take a look into the source code of FrameDecoder to understand how it
>> works (it's pretty simple actually):
>>
>>  * http://tinyurl.com/5mcwnd
>>
>>> (b) read a certain amount of bytes (I can make a guess how long an
>>> average message is), see if there is a complete message in it, if read
>>> in the next call twice as much and so on
>>> disadvantage: I may have useless calls to decode(...) and everything
>>> in it if the fixed buffer size is too small for a message.
>>
>> You don't need to do this by yourself.  Netty's I/O engine will manage
>> the size of the receive buffer automatically.  If the buffer gets full,
>> the new read buffer will have more capacity.  If the buffer is far from
>> being full, the next read buffer will have less capacity.  Plus, you can
>> configure it.  Plase take a look at the Javadoc of
>> NioSocketChannelConfig:
>>
>>  * http://tinyurl.com/6e282b
>>
>> Also, you might want to look into the default buffer size prediction
>> algorithm:
>>
>>  * http://tinyurl.com/5877hv
>>
>>> What do you think will be more performant with Netty's FrameDecoder
>>> and ChannelBuffer?
>>
>> I think it should perform just fine even if you don't apply the two
>> techniques you've mentioned above.
>>
>>> Btw, why are the method names for the readIndex and writeIndex in
>>> ChannelBuffer not named get..()/set...() ?
>>
>> In respect of NIO ByteBuffer.  For example, ByteBuffer.position()
>> has the same naming convention.  Wanted for users to be comfort when
>> they transit from NIO BB to Netty CB.  AND less keystrokes? :)
>>
>> HTH,
>> Trustin
>>
>> --
>> Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>>
 
-- 
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20081124/91e90e15/attachment.bin