mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "이희승 (Trustin Lee) <trus...@gmail.com>
Subject Re: Interesting direct buffer vs heap buffer micro benchmark
Date Mon, 07 Apr 2008 07:05:22 GMT
I have implemented a quick prototype of mina JNI extension and the
ByteBuffer allocated by glibc malloc seems to show the same performance
characteristics as expected.

However, I was not able to overcome the cost of direct buffer
allocation, which is extremely high (apx 10 times).  Pooling yields much
better performance, but it's still very slow (2~5 times depending on
situation.)  I think the allocation can also outperform heap buffer if
we force a user to return the buffer to the pool explicitly, but it's an
expressway to OOM.

So... I guess we need to stick to heap buffers unfortunately although I
still want to find out a way to reduce the buffer allocation which
occurs in I/O processor for each read operation.  It certainly takes up
memory bandwidth because the newly allocated buffer is filled with NULs
inevitably.  AFAIK, there's no workaround in JNI for this issue as long
as we use heap buffers.

We could create a big read buffer and fire a messageReceived event with
its sliced part, but we still have an issue with figuring out what part
of the read buffer is being referenced by user.  We can be notified when
the slice is garbage collected using PhantomReference, but its
performance is poor according to my test.  Of course, again, we can ask
a user to notify the I/O processor when he or she doesn't need it
anymore, but it's inconvenient and error-prone.

I don't think JVM will ever provide us a way to create a dirty byte
array, so I guess I've hit the dead end for now.

"이희승 (Trustin Lee) <trustin@gmail.com>" wrote:
> Emmanuel Lecharny wrote:
>> "이희승 (Trustin Lee) <trustin@gmail.com>" wrote:
>>> Hi,
>>>
>>>   
>> <snip/>
>>> I was also able to observe similar test result in JDK 1.5.0.15, but
>>> running the heap test first always resulted in extremely slow direct
>>> buffer performance (3x slowdown), which is also interesting.  Why
>>> hotspot so inconsistent like this?
>>>   
>> I have tested it with IBM JVM, and I got the very same strange
>> inconsistency... It would be interesting to profile the test to
>> understand what really happens internally.
> 
> It seems like the hotspot engine optimizes the test(...) method to work
> better with a certain type of byte buffer.  I inlined the test(...)
> method into the two test methods, and now I am getting consistent
> result.  Direct buffer outperforms heap buffer for all cases in Java 6,
> except for the allocation and deallocation.  If we can provide
> reasonable solution for pooling direct buffers, we will be able to gain
> more performance out of MINA.
> 
> BTW, it is interesting that direct buffer outperforms heap buffer.
> Kudos to the JVM developers!
> 
> ---- REVISED CODE ----
> import java.nio.ByteBuffer;
> 
> import org.junit.Test;
> 
> 
> public class ByteBufferTest {
>     @Test
>     public void heap() {
>         ByteBuffer buf = ByteBuffer.allocate(2048);
>         long startTime = System.currentTimeMillis();
>         for (int i = 1048576; i > 0; i --) {
>             buf.clear();
>             while (buf.hasRemaining()) {
>                 buf.getInt(buf.position());
>                 buf.putInt((byte) 0);
>             }
>         }
>         long endTime = System.currentTimeMillis();
>         System.out.println("heap: " + (endTime - startTime));
>     }
> 
>     @Test
>     public void direct() {
>         ByteBuffer buf = ByteBuffer.allocateDirect(2048);
>         long startTime = System.currentTimeMillis();
>         for (int i = 1048576; i > 0; i --) {
>             buf.clear();
>             while (buf.hasRemaining()) {
>                 buf.getInt(buf.position());
>                 buf.putInt((byte) 0);
>             }
>         }
>         long endTime = System.currentTimeMillis();
>         System.out.println("direct: " + (endTime - startTime));
>     }
> 
> }
> 
> 

-- 
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/


Mime
View raw message