[
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)
