You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2016/03/21 22:40:25 UTC
[jira] [Comment Edited] (HBASE-15453) [Performance] Considering
reverting HBASE-10015 - reinstate synchronized in StoreScanner
[ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205211#comment-15205211 ]
Andrew Purtell edited comment on HBASE-15453 at 3/21/16 9:39 PM:
-----------------------------------------------------------------
The patch hurts a little on 7u and helps a little bit more on 8u on my open source laptop. Magnitude of difference will vary by CPU generation too I'm sure.
On Intel Core i5 CPU M 520 @ 2.40GHz (cpufreq governor userspace freq 2.40GHz)
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
Without patch: 10 runs mean:2077.1 sigma:91.84601243385582
With patch: 10 runs mean:2782.6 sigma:116.52313075093717
---
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
Without patch: 10 runs mean:2129.6 sigma:75.55289537800653
With patch: 10 runs mean:1805.7 sigma:30.870860046328477
was (Author: apurtell):
The patch hurts a little on 7u and helps a little bit more on 8u on my open source laptop. Magnitude of difference will vary by CPU generation too I'm sure.
On Intel Core i5 CPU M 520 @ 2.40GHz (cpufreq governor userspace freq 2.40GHz)
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
Without: 10 runs mean:2077.1 sigma:91.84601243385582
With: 10 runs mean:2782.6 sigma:116.52313075093717
---
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
Without: 10 runs mean:2129.6 sigma:75.55289537800653
With: 10 runs mean:1805.7 sigma:30.870860046328477
> [Performance] Considering reverting HBASE-10015 - reinstate synchronized in StoreScanner
> ----------------------------------------------------------------------------------------
>
> Key: HBASE-15453
> URL: https://issues.apache.org/jira/browse/HBASE-15453
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Critical
> Attachments: 15453-0.98.txt
>
>
> In HBASE-10015 back then I found that intrinsic locks (synchronized) in StoreScanner are slower that explicit locks.
> I was surprised by this. To make sure I added a simple perf test and many folks ran it on their machines. All found that explicit locks were faster.
> Now... I just ran that test again. On the latest JDK8 I find that now the intrinsic locks are significantly faster:
> (OpenJDK Runtime Environment (build 1.8.0_72-b15))
> Explicit locks:
> 10 runs mean:2223.6 sigma:72.29412147609237
> Intrinsic locks:
> 10 runs mean:1865.3 sigma:32.63755505548784
> I confirmed the same with timing some Phoenix scans. We can save a bunch of time by changing this back
> Arrghhh... So maybe it's time to revert this now...?
> (Note that in trunk due to [~ram_krish]'s work, we do not lock in StoreScanner anymore)
> I'll attach the perf test and a patch that changes lock to synchronized, if some folks could run this on 0.98, that'd be great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)