You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@rocketmq.apache.org by "wangkai (JIRA)" <ji...@apache.org> on 2017/08/25 08:05:02 UTC

[jira] [Closed] (ROCKETMQ-274) Some code may be can improvement

     [ https://issues.apache.org/jira/browse/ROCKETMQ-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

wangkai closed ROCKETMQ-274.
----------------------------
    Resolution: Not A Problem

Different device has different cpu endians,we can use unsafe in single machine , but the codec need to match different device ,so may be we need at least two codec way for file system and network, but the improvement is not so clear for much work.

> Some code may be can improvement
> --------------------------------
>
>                 Key: ROCKETMQ-274
>                 URL: https://issues.apache.org/jira/browse/ROCKETMQ-274
>             Project: Apache RocketMQ
>          Issue Type: Improvement
>          Components: rocketmq-store
>    Affects Versions: 4.2.0-incubating
>            Reporter: wangkai
>            Assignee: yukon
>            Priority: Minor
>             Fix For: 4.2.0-incubating
>
>
> in class [CommitLog]
> I see many put Int or Long operation like this in function doAppend(...), We will result a better performance if we use DirectByteBuffer instead of HeapByteBuffer and use unsafe to operate the buffer. 
> {code:java}
> // Initialization of storage space
>             this.resetByteBuffer(msgStoreItemMemory, msgLen);
>             // 1 TOTALSIZE
>             this.msgStoreItemMemory.putInt(msgLen);
>             // 2 MAGICCODE
>             this.msgStoreItemMemory.putInt(CommitLog.MESSAGE_MAGIC_CODE);
>             // 3 BODYCRC
>             this.msgStoreItemMemory.putInt(msgInner.getBodyCRC());
>             // 4 QUEUEID
>             this.msgStoreItemMemory.putInt(msgInner.getQueueId());
>             // 5 FLAG
>             this.msgStoreItemMemory.putInt(msgInner.getFlag());
>             // 6 QUEUEOFFSET
>             this.msgStoreItemMemory.putLong(queueOffset);
>             // 7 PHYSICALOFFSET
>             this.msgStoreItemMemory.putLong(fileFromOffset + byteBuffer.position());
>             // 8 SYSFLAG
>             this.msgStoreItemMemory.putInt(msgInner.getSysFlag());
>             // 9 BORNTIMESTAMP
>             this.msgStoreItemMemory.putLong(msgInner.getBornTimestamp());
>             // 10 BORNHOST
>             this.resetByteBuffer(hostHolder, 8);
>             this.msgStoreItemMemory.put(msgInner.getBornHostBytes(hostHolder));
>             // 11 STORETIMESTAMP
>             this.msgStoreItemMemory.putLong(msgInner.getStoreTimestamp());
>             // 12 STOREHOSTADDRESS
>             this.resetByteBuffer(hostHolder, 8);
>             this.msgStoreItemMemory.put(msgInner.getStoreHostBytes(hostHolder));
>             //this.msgBatchMemory.put(msgInner.getStoreHostBytes());
>             // 13 RECONSUMETIMES
>             this.msgStoreItemMemory.putInt(msgInner.getReconsumeTimes());
>             // 14 Prepared Transaction Offset
>             this.msgStoreItemMemory.putLong(msgInner.getPreparedTransactionOffset());
>             // 15 BODY
>             this.msgStoreItemMemory.putInt(bodyLength);
>             if (bodyLength > 0)
>                 this.msgStoreItemMemory.put(msgInner.getBody());
>             // 16 TOPIC
>             this.msgStoreItemMemory.put((byte) topicLength);
>             this.msgStoreItemMemory.put(topicData);
>             // 17 PROPERTIES
>             this.msgStoreItemMemory.putShort((short) propertiesLength);
>             if (propertiesLength > 0)
>                 this.msgStoreItemMemory.put(propertiesData);
> {code}
> after the puts , at the line 1305:
> {code:java}
> byteBuffer.put(this.msgStoreItemMemory.array(), 0, msgLen);
> {code}
> it always put from zero of this buffer , but the resetByteBuffer function use flip() to "clean ?" the buffer , what if just do clear() the buffer in the function and limit it outside when need.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)