mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alwyn Schoeman" <alwyn.schoe...@gmail.com>
Subject Re: Recycling ByteBuffers
Date Mon, 11 Jun 2007 06:08:45 GMT
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 <trustin@gmail.com> wrote:
>
> Hi Alwyn,
>
> On 6/11/07, Alwyn Schoeman <alwyn.schoeman@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message