Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Severe Severe
    • Resolution: Fixed
    • Affects Version/s: 3.1 GA
    • Fix Version/s: 3.1.1 GA
    • Component/s: None
    • Labels:
      None
    • Customer Case:

      Description

      While evaluating NON EMPTY and large axes, Mondrian spends a lot of CPU building the rows axis. Apparently it only happens when one of the constraining axes is a hierarchy without an ALL member.

      Sampling stack trace yields the following:

      1.

      "main" prio=6 tid=0x024c9400 nid=0x12d0 runnable [0x009de000..0x009dfe28]
         java.lang.Thread.State: RUNNABLE
      at mondrian.olap.LevelBase.getUniqueName(LevelBase.java:68)
      at mondrian.olap.OlapElementBase.equals(OlapElementBase.java:45)
      at mondrian.rolap.RolapCubeLevel.equals(RolapCubeLevel.java:201)
      at mondrian.rolap.RolapCubeMember.equals(RolapCubeMember.java:159)
      at mondrian.rolap.RolapCubeMember.equals(RolapCubeMember.java:145)
      at java.util.ArrayList.indexOf(ArrayList.java:216)
      at java.util.ArrayList.contains(ArrayList.java:199)
      at mondrian.rolap.RolapResult.mergeAxes(RolapResult.java:1864)
      at mondrian.rolap.RolapResult.evalExecute(RolapResult.java:602)
      at mondrian.rolap.RolapResult.<init>(RolapResult.java:382)
      at mondrian.rolap.RolapConnection.execute(RolapConnection.java:560)
      at mondrian.test.TestContext.executeQuery(TestContext.java:481)
      at mondrian.test.TestContext.assertQueryReturns(TestContext.java:906)
      at mondrian.test.SchemaTest.testFoo(SchemaTest.java:2519)

      2.
      "main" prio=6 tid=0x024c9400 nid=0x12d0 runnable [0x009de000..0x009dfe28]
         java.lang.Thread.State: RUNNABLE
      at java.lang.String.lastIndexOf(String.java:1868)
      at java.lang.StringBuilder.lastIndexOf(StringBuilder.java:419)
      at mondrian.olap.Util.replace(Util.java:383)
      at mondrian.olap.Util.quoteMdxIdentifier(Util.java:194)
      at mondrian.olap.Util.quoteMdxIdentifier(Util.java:186)
      at mondrian.olap.CubeBase.getUniqueName(CubeBase.java:66)
      at mondrian.olap.OlapElementBase.equals(OlapElementBase.java:45)
      at mondrian.rolap.RolapCubeLevel.equals(RolapCubeLevel.java:201)
      at mondrian.rolap.RolapCubeMember.equals(RolapCubeMember.java:159)
      at mondrian.rolap.RolapCubeMember.equals(RolapCubeMember.java:145)
      at java.util.ArrayList.indexOf(ArrayList.java:216)
      at java.util.ArrayList.contains(ArrayList.java:199)
      at mondrian.rolap.RolapResult.mergeAxes(RolapResult.java:1864)
      at mondrian.rolap.RolapResult.evalExecute(RolapResult.java:602)
      at mondrian.rolap.RolapResult.<init>(RolapResult.java:382)
      at mondrian.rolap.RolapConnection.execute(RolapConnection.java:560)
      at mondrian.test.TestContext.executeQuery(TestContext.java:481)
      at mondrian.test.TestContext.assertQueryReturns(TestContext.java:906)
      at mondrian.test.SchemaTest.testFoo(SchemaTest.java:2519)

      The problem is an O(n^2) algorithm for building lists (add a member to a list only if the list does not already contain the member), but is exacerbated by MONDRIAN-473 (inefficient implementation of RolapCubeMember.equals()).

      I am going to fix the list-building algorithm; MONDRIAN-473 can wait.

        Activity

        Hide
        Julian Hyde added a comment -
        Fixed in change 12668, which will be in mondrian-3.1.1 or mondrian-3.1.2.
        Show
        Julian Hyde added a comment - Fixed in change 12668, which will be in mondrian-3.1.1 or mondrian-3.1.2.
        Hide
        Vikram NS added a comment -
        Fixed and Validated using the 3.7.0-RC1 build on 10/11/2010.
        Show
        Vikram NS added a comment - Fixed and Validated using the 3.7.0-RC1 build on 10/11/2010.

          People

          • Assignee:
            Julian Hyde
            Reporter:
            Julian Hyde
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: