Trying to avoid / cache buffer allocation when serializing object

[Shay Banon]

Yea, that was my idea for pooling channel buffers, not to serialize directly
to the socket :). Maybe wrapped internally or externally with a soft
reference.

On Thu, Nov 11, 2010 at 4:10 AM, "이희승 (Trustin Lee)" <trustin at gmail.com>wrote:

> I don't think there's a way to avoid buffer allocation completely.  An
> object needs to be serialized into some form and we need some space to
> do that.  We can't write byte by byte during serialization because it
> will be very slow.
>
> If you want to reduce the cost of buffer allocation, you might want to
> pool it, but you have to be careful about concurrency issues.
>
>  PooledChannelBuffer buf = pool.acquire();
>  ...
>  ch.write(buf).addListener(new ChannelFutureListener() {
>      void operationComplete(...) {
>          buf.release();
>      }
>  });
>
> Actually, I think this could be part of Netty! :-)
>
> Shay Banon wrote:
> > Hi,
> >
> >    I was wondering if there is a nice way to try and avoid buffer
> > allocation when serializing objects. I have my own way of serializing
> > objects, but the idea is very similar to ObjectEncoder, which allocates
> > a new buffer for each written message. I understand that its very
> > difficult to serialize directly to the socket in non blocking IO, but
> > was wondering if there is a good way to not allocate a buffer each time
> > but maybe reuse buffers.
> >
> >    I could build my own cache of buffers, get one before writing and
> > release it when the write is completed. Wondering if there is a better
> > way to do it...
> >
> > -shay.banon
> >
> >
> >
> > _______________________________________________
> > netty-users mailing list
> > netty-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/netty-users
>
> --
> Trustin Lee - http://gleamynode.net/
>
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20101112/c569894b/attachment.html