FAQ
Lars Hofhansl created HBASE-15453:
-------------------------------------

              Summary: Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner
                  Key: HBASE-15453
                  URL: https://issues.apache.org/jira/browse/HBASE-15453
              Project: HBase
           Issue Type: Bug
             Reporter: Lars Hofhansl


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:

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)

Search Discussions

  • Lars Hofhansl (JIRA) at Mar 13, 2016 at 11:02 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Lars Hofhansl updated HBASE-15453:
    ----------------------------------
         Attachment: 15453-0.98.txt

    Here's the patch with test.

    [~apurtell], [~stack], and anybody else, if you guys have some time, could you apply this patch and run TestScanFilterPerformance?
    Then undo the changes to StoreScanner and ReversedStoreScanner and run the test again.

    The test does some warm up, then runs the perf test 10 times and calculates mean and standard deviation.

    Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner
    ---------------------------------------------------------------------------

    Key: HBASE-15453
    URL: https://issues.apache.org/jira/browse/HBASE-15453
    Project: HBase
    Issue Type: Bug
    Reporter: Lars Hofhansl
    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:
    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)
  • Lars Hofhansl (JIRA) at Mar 13, 2016 at 11:14 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192562#comment-15192562 ]

    Lars Hofhansl commented on HBASE-15453:
    ---------------------------------------

    Another 4 runs:
    Intrinsic:
    10 runs mean:1918.1 sigma:24.122396232547054
    10 runs mean:1898.5 sigma:22.531089631884207

    Explicit:
    10 runs mean:2164.2 sigma:21.48394749574668
    10 runs mean:2145.9 sigma:22.322410264126948

    Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner
    ---------------------------------------------------------------------------

    Key: HBASE-15453
    URL: https://issues.apache.org/jira/browse/HBASE-15453
    Project: HBase
    Issue Type: Bug
    Reporter: Lars Hofhansl
    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:
    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)
  • Lars Hofhansl (JIRA) at Mar 14, 2016 at 4:12 am
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Lars Hofhansl updated HBASE-15453:
    ----------------------------------
         Description:
    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.


       was:
    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:

    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.


    Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner
    ---------------------------------------------------------------------------

    Key: HBASE-15453
    URL: https://issues.apache.org/jira/browse/HBASE-15453
    Project: HBase
    Issue Type: Bug
    Reporter: Lars Hofhansl
    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)
  • Lars Hofhansl (JIRA) at Mar 14, 2016 at 4:24 am
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192726#comment-15192726 ]

    Lars Hofhansl commented on HBASE-15453:
    ---------------------------------------

    Work machine (OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4))
    Intrinsic:
    10 runs mean:1749.9 sigma:25.76606295109907
    10 runs mean:1782.8 sigma:54.50100916496868

    Explicit:
    10 runs mean:1487.6 sigma:117.99169462296913
    10 runs mean:1479.6 sigma:41.01511916354749

    So on JDK7 the explicit locks are (still inexplicably) faster.

    Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner
    ---------------------------------------------------------------------------

    Key: HBASE-15453
    URL: https://issues.apache.org/jira/browse/HBASE-15453
    Project: HBase
    Issue Type: Bug
    Reporter: Lars Hofhansl
    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)
  • Lars Hofhansl (JIRA) at Mar 14, 2016 at 5:33 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193701#comment-15193701 ]

    Lars Hofhansl commented on HBASE-15453:
    ---------------------------------------

    What's the best way to just commit the perf test? I want to easily be able to run it without compiling and installing HBase somewhere.

    Right now it's a test that in its failure message displays the runtime. Any better way to do this? I suppose I could check in but comment the \@test marker by default...?
    Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner
    ---------------------------------------------------------------------------

    Key: HBASE-15453
    URL: https://issues.apache.org/jira/browse/HBASE-15453
    Project: HBase
    Issue Type: Bug
    Reporter: Lars Hofhansl
    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)
  • stack (JIRA) at Mar 14, 2016 at 7:51 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194017#comment-15194017 ]

    stack commented on HBASE-15453:
    -------------------------------

    Yeah... remove the @Test... Add a main that calls your test on this class? You want to test a long scan? We have test of a 10k scan in PE. You want to run longer than this? The full 5M table?
    Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner
    ---------------------------------------------------------------------------

    Key: HBASE-15453
    URL: https://issues.apache.org/jira/browse/HBASE-15453
    Project: HBase
    Issue Type: Bug
    Reporter: Lars Hofhansl
    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)
  • stack (JIRA) at Mar 14, 2016 at 7:52 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    stack updated HBASE-15453:
    --------------------------
            Assignee: Lars Hofhansl
            Priority: Critical (was: Major)
         Component/s: Performance
          Issue Type: Improvement (was: Bug)
             Summary: [Performance] Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner (was: Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner)

    Marking Critical because seems like big benefit for simple change. I can try this later....
    [Performance] Considering reverting HBASE-10015 - reinstance 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)
  • Lars Hofhansl (JIRA) at Mar 15, 2016 at 3:51 am
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194697#comment-15194697 ]

    Lars Hofhansl commented on HBASE-15453:
    ---------------------------------------

    Note that HBASE-10015 in had many folks confirm the numbers. Explicit locks were better back then.
    Also note that with JDK7 tested at work, Explicit locks were still better.
    Only with JDK8 at home did I find that intrinsic locks (synchronized) was better.

    It's not slam dunk, it depends on the JDK.

    [Performance] Considering reverting HBASE-10015 - reinstance 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)
  • Lars Hofhansl (JIRA) at Mar 15, 2016 at 4:49 am
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194725#comment-15194725 ]

    Lars Hofhansl commented on HBASE-15453:
    ---------------------------------------

    For a Phoenix count\(*) query on the JDK8 machine I measure a 7.5% end-to-end improvement.
    I also tried the new JDK8 StampedLock, which should be better than ReentrantLock especially when not contended... Came to about the same as the intrinsic locks.

    [Performance] Considering reverting HBASE-10015 - reinstance 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)
  • Lars Hofhansl (JIRA) at Mar 15, 2016 at 4:58 am
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Lars Hofhansl updated HBASE-15453:
    ----------------------------------
         Summary: [Performance] Considering reverting HBASE-10015 - reinstate synchronized in StoreScanner (was: [Performance] Considering reverting HBASE-10015 - reinstance synchronized in StoreScanner)
    [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)
  • Andrew Purtell (JIRA) at Mar 21, 2016 at 9:39 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205211#comment-15205211 ]

    Andrew Purtell commented on HBASE-15453:
    ----------------------------------------

    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)
  • Andrew Purtell (JIRA) at Mar 21, 2016 at 9:40 pm
    [ 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)
  • Lars Hofhansl (JIRA) at Mar 23, 2016 at 7:20 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15208984#comment-15208984 ]

    Lars Hofhansl commented on HBASE-15453:
    ---------------------------------------

    So what do we do here?
    I'll do one more test later... See how it compares to no memory fencing at all.

    So perf loss on JDK 7 is significant, so is the perf gain with JDK 8.
    [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)
  • stack (JIRA) at Mar 23, 2016 at 9:12 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15209184#comment-15209184 ]

    stack commented on HBASE-15453:
    -------------------------------

    JDK7 is dead.
    [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)
  • Elliott Clark (JIRA) at Mar 23, 2016 at 9:24 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15209200#comment-15209200 ]

    Elliott Clark commented on HBASE-15453:
    ---------------------------------------

    Yay
    [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)
  • Andrew Purtell (JIRA) at Mar 23, 2016 at 10:34 pm
    [ https://issues.apache.org/jira/browse/HBASE-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15209318#comment-15209318 ]

    Andrew Purtell commented on HBASE-15453:
    ----------------------------------------

    Agreed, make the change. We should all be advocating 8 runtimes.
    [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)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupissues @
categorieshbase, hadoop
postedMar 13, '16 at 10:58p
activeMar 23, '16 at 10:34p
posts17
users1
websitehbase.apache.org

1 user in discussion

Andrew Purtell (JIRA): 17 posts

People

Translate

site design / logo © 2021 Grokbase