[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476611#comment-16476611 ]
stack commented on HBASE-20564: ------------------------------- Thanks for finding issue [~yuzhih...@gmail.com] what tests were failing? Mind if I fix? I don't want to lose speedups that took me a while. This is our hottest code path. > Tighter ByteBufferKeyValue Cell Comparator > ------------------------------------------ > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance > Reporter: stack > Assignee: stack > Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)