You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Alwyn Schoeman <al...@gmail.com> on 2007/06/10 20:04:47 UTC
Re: Recycling ByteBuffers
A few years ago I wrote a NIO framework for my then employer.
In that framework I used 1 directly allocated buffer per connection (could
have been 1 for read and 1 for write). I also reused that buffer for all
data on that connection.
I'm curious as to how that would compare to Mina's current methods.
Actually I have an interest in getting the Mina based version to outperform
my original one as I'm
being paid to port the platform over to Mina.
My gut tells me that reusing a single directly allocated buffer should be
quicker than instantiating one on the heap on demand, but I'm hoping that
other factors like synchronization,etc
makes is slower....
--
Alwyn Schoeman
Re: Recycling ByteBuffers
Posted by Alwyn Schoeman <al...@gmail.com>.
Ok, now I just need to make sure my understanding of Mina is such that I can
get the best performance :)
The framework I spoke about was used in cases of few connections and very
high volumes.
On 6/11/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Alwyn,
>
> On 6/11/07, Alwyn Schoeman <al...@gmail.com> wrote:
> > A few years ago I wrote a NIO framework for my then employer.
> >
> > In that framework I used 1 directly allocated buffer per connection
> (could
> > have been 1 for read and 1 for write). I also reused that buffer for
> all
> > data on that connection.
> >
> > I'm curious as to how that would compare to Mina's current methods.
> > Actually I have an interest in getting the Mina based version to
> outperform
> > my original one as I'm
> > being paid to port the platform over to Mina.
> >
> > My gut tells me that reusing a single directly allocated buffer should
> be
> > quicker than instantiating one on the heap on demand, but I'm hoping
> that
> > other factors like synchronization,etc
> > makes is slower....
>
> Holding a pre-allocated buffer per connection can cause memory
> consumption issue when the number of connections increase but the
> traffic is very little; framework will waste the memory.
>
> We chose to allocate the buffer whenever we perform a read or write
> operation in belief that JVM will take care of memory allocation
> issues. In our performance test, allocating a heap buffer was faster
> than pooling buffers. It is because JVM has 'young' memory area that
> performs memory allocation in O(1) (i.e. constant) time, and probably
> because synchronized keyword takes time.
>
> Additionally, managing a pool makes acquiring and releasing buffers
> complicated so users can make a mistake.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
--
Alwyn Schoeman
Re: Recycling ByteBuffers
Posted by Trustin Lee <tr...@gmail.com>.
Hi Alwyn,
On 6/11/07, Alwyn Schoeman <al...@gmail.com> wrote:
> A few years ago I wrote a NIO framework for my then employer.
>
> In that framework I used 1 directly allocated buffer per connection (could
> have been 1 for read and 1 for write). I also reused that buffer for all
> data on that connection.
>
> I'm curious as to how that would compare to Mina's current methods.
> Actually I have an interest in getting the Mina based version to outperform
> my original one as I'm
> being paid to port the platform over to Mina.
>
> My gut tells me that reusing a single directly allocated buffer should be
> quicker than instantiating one on the heap on demand, but I'm hoping that
> other factors like synchronization,etc
> makes is slower....
Holding a pre-allocated buffer per connection can cause memory
consumption issue when the number of connections increase but the
traffic is very little; framework will waste the memory.
We chose to allocate the buffer whenever we perform a read or write
operation in belief that JVM will take care of memory allocation
issues. In our performance test, allocating a heap buffer was faster
than pooling buffers. It is because JVM has 'young' memory area that
performs memory allocation in O(1) (i.e. constant) time, and probably
because synchronized keyword takes time.
Additionally, managing a pool makes acquiring and releasing buffers
complicated so users can make a mistake.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6