Github user sachouche commented on a diff in the pull request:

    https://github.com/apache/drill/pull/1060#discussion_r165698800
  
    --- Diff: exec/memory/base/src/main/java/io/netty/buffer/DrillBuf.java ---
    @@ -703,7 +703,18 @@ protected void _setLong(int index, long value) {
     
       @Override
       public ByteBuf getBytes(int index, ByteBuf dst, int dstIndex, int 
length) {
    -    udle.getBytes(index + offset, dst, dstIndex, length);
    +    final int BULK_COPY_THR = 1024;
    --- End diff --
    
    Vlad,
    
    - I had a chat with @bitblender and he explains that Java was invoking a 
stub (not a function call) to perform copyMemory; he agreed copyMemory will be 
slower for small buffers and the task was to determine the cutoff point
    - My tests (I will send you my test) indicate that a length of 1024bytes is 
the length were copyMemory starts performing exactly as getByte()
    
    NOTE - I am using JRE 1.8; static buffers initialized once; payload 1MB 
(1048576bytes) and loop-count of 102400; MacOS High Sierra; 1 thread, 4GB MX, MS


---

Reply via email to