question about performance of FrameDecoder and ChannelBuffer

[Christian Migowski]

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/
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
>