[ https://issues.apache.org/jira/browse/HBASE-18542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141932#comment-16141932 ]
Amit Patel commented on HBASE-18542: ------------------------------------ I redid the benchmarks using JMH as suggested [~enis] (thanks for the examples!). I ran tests on Clock#now and Clock#update for each clock implementation with 1, 4, and then 16 threads. The hybrid logical clock implementation doesn't look too good and does not scale with additional threads compared to the system and system monotonic clock implementation. The main culprit is the use of the synchronized blocks in the HLC's Clock#now and Clock#update so these results would represent the worst case. https://docs.google.com/spreadsheets/d/1ndAVSwQ4yBqqu28_9eREg9qqDrpcXVt7TfTJOQWUq8Q/edit?usp=sharing Overall, there is still work that needs to be done to improve performance for the hybrid logical clock implementation. > [HLC] Performance microbenchmarks > --------------------------------- > > Key: HBASE-18542 > URL: https://issues.apache.org/jira/browse/HBASE-18542 > Project: HBase > Issue Type: Sub-task > Reporter: Appy > Assignee: Amit Patel > Attachments: HBASE-18542.HBASE-14070.HLC.001.patch > > > Need tests to benchmark performance of Clock#now() and update() functions > (for all types of clocks). > If update() is too costly, we can do optimizations in > ExecuteProceduresRemoteCall#call(), HRegion#replayRecoveredEdits() and other > places where we call update() in loop. Instead, it might be faster to > calculate max timestamp in loop and call update() just once. -- This message was sent by Atlassian JIRA (v6.4.14#64029)