[
https://issues.apache.org/jira/browse/HBASE-13817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569451#comment-14569451
]
Anoop Sam John commented on HBASE-13817:
----------------------------------------
{quote}
Over in Bytes, we ask what the ordering is and use it:
static final boolean littleEndian =
ByteOrder.nativeOrder().equals(ByteOrder.LITTLE_ENDIAN);
Was wondering why you don't do similar in IPCUtil.
{quote}
It is different Stack. There the usage is in Unsafe part. There we really on
Unsafe APIs to read and write and the system's byte order (native order) is
what matters. That any way we can not control. We always write big endian
(HFile, WAL, socket) . So if the system order is little endian, we have to
reverse the bytes of int/long etc before we write.
Here we are not using the Unsafe. We do BB APIs. There the order is what
matters. Which we can control using setter. The default value for this for Java
NIO byte buffer impls are BigEndian only. I just added to make it double
confirm. May be skip? Just add an assert alone? Any way I dont think Java will
change this BB behavior in later versions.
The StreamUtils writeInt API is used only from these Cell impl classes (as of
now). That was one of the reason why I changed the util API in 1st version of
patch.
> ByteBufferOuputStream - add writeInt support
> --------------------------------------------
>
> Key: HBASE-13817
> URL: https://issues.apache.org/jira/browse/HBASE-13817
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-13817.patch, HBASE-13817_V2.patch
>
>
> While writing Cells to this stream, to make the CellBlock ByteBuffer, we do
> write length of the cell as int. We use StreamUtils to do this which will
> write each byte one after the other. So 4 write calls on Stream.(OutputSteam
> has only this support) With ByteBufferOuputStream we have the overhead of
> checking for size limit and possible grow with every write call. Internally
> this stream writes to a ByteBuffer. Again inside the ByteBuffer
> implementations there is position limit checks. If we do write these length
> as int in one go we can reduce this overhead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
