[jira] [Comment Edited] (HBASE-19684) BlockCacheKey toString Performance

["BELUGA BEHR (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-19684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16308086#comment-16308086 ] 

BELUGA BEHR edited comment on HBASE-19684 at 1/2/18 2:01 PM:
-------------------------------------------------------------

[~Apache9] Thanks for the review. :)

While I admit that it is easier to read an implementation with StringBuilder, but in my micro-bench-marking, I found that the concat implementation was faster by a minuscule, but observable, amount.  This was a little surprising, but StringBuilder class has to do some additional work around ensuring the size of its internal buffer, including null checks, even if it doesn't change the size of the buffer.  In addition, the default buffer size for StringBuffer is 16 and it is possible that a Long could be [up to 19 characters long|http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/lang/Long.java#Long.stringSize%28long%29], so it may have to resize the buffer and copy contents, etc. The concat implementation is therefore more predictable in performance, as it will always perform the same steps regardless of sizes.

If however, you like the readability of it, I understand and can make the change.


was (Author: belugabehr):
[~Apache9] Thanks for the review. :)

While I admit that it is easier to read an implementation with StringBuilder, but in my micro-bench-marking, I found that the concat implementation was faster.  This was a little surprising, but StringBuilder class has to do some additional work around ensuring the size of its internal buffer, including null checks, even if it doesn't change the size of the buffer.  In addition, the default buffer size for StringBuffer is 16 and it is possible that a Long could be [up to 19 characters long|http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/lang/Long.java#Long.stringSize%28long%29], so it may have to resize the buffer and copy contents, etc. The concat implementation is therefore more predictable in performance, as it will always perform the same steps regardless of sizes.

> BlockCacheKey toString Performance
> ----------------------------------
>
>                 Key: HBASE-19684
>                 URL: https://issues.apache.org/jira/browse/HBASE-19684
>             Project: HBase
>          Issue Type: Improvement
>          Components: hbase
>    Affects Versions: 3.0.0
>            Reporter: BELUGA BEHR
>            Assignee: BELUGA BEHR
>            Priority: Trivial
>         Attachments: HBASE-19684.1.patch
>
>
> {code:titile=BlockCacheKey.java}
>   @Override
>   public String toString() {
>     return String.format("%s_%d", hfileName, offset);
>   }
> {code}
> I found through bench-marking that the following code is 10x faster.
> {code:titi\le=BlockCacheKey.java}
>   @Override
>   public String toString() {
>     return hfileName.concat("_").concat(Long.toString(offset));
>   }
> {code}
> Normally it wouldn't matter for a _toString()_ method, but this is comes into play because {{MemcachedBlockCache}} uses it.
> {code:title=MemcachedBlockCache.java}
>   @Override
>   public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf) {
>     if (buf instanceof HFileBlock) {
>       client.add(cacheKey.toString(), MAX_SIZE, (HFileBlock) buf, tc);
>     } else {
>       if (LOG.isDebugEnabled()) {
>         LOG.debug("MemcachedBlockCache can not cache Cacheable's of type "
>             + buf.getClass().toString());
>       }
>     }
>   }
> {code}



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