JBRULES
  1. JBRULES
  2. JBRULES-2982

Massive performance degradation from 5.2.0.M1 to 5.2.0.M2

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Critical Critical
    • Resolution: Done
    • Affects Version/s: 5.2.0.M2
    • Fix Version/s: 5.2.0.CR1
    • Component/s: drools-core (expert)
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      the drools-planner SolutionInitializer takes 75 minutes to complete im 5.2.0.M2
      5.2.0.M1 took 9,5 Minutes

      It also seems that accumulation queries with init, action, result sections break down completely in performance.
      The following query takes now 3 minutes 45 secs to complete. Before it was ~1 sec.
      The cardinalities:
      PostingPeriodOpt = 5
      MediumLocationOpt = 25000
      MediumBookingOpt = 13000

      query "queryMediumPartlyTaken"
      $pp : PostingPeriodOpt()
      $mlo : MediumLocationOpt(mTypeId == $pp.mTypeId)
      $mp: MediumPeriodUsage( subOptimal > 0 ) from accumulate(
      $mbo : MediumBookingOpt ( mediId == $mlo.mediId, eval(timeInterval.overlaps($pp.getCycle())) ),
      init ( MediumPeriodUsage $mpu = new MediumPeriodUsage($mlo, $pp); ),
      action( $mpu.addBooking( $mbo.getIndexRange() ); ),
      result( $mpu )
      )
      end

        Issue Links

          Activity

          Hide
          Geoffrey De Smet
          added a comment -

          In examination I see a factor 2.13 between drools-compiler 5.1.1 and 5.2.0.CR1 (actually the offending change was from M1 to M2).
          In nurse rostering it's a factor 1.3

          Show
          Geoffrey De Smet
          added a comment - In examination I see a factor 2.13 between drools-compiler 5.1.1 and 5.2.0.CR1 (actually the offending change was from M1 to M2). In nurse rostering it's a factor 1.3
          Hide
          Edson Tirelli
          added a comment -

          Thanks for reporting.

          The problem was that the new parser was generating a slightly different Descr AST for the accumulate statement, which in turn was forcing the ReteOO builder to create subnetworks for all accumulate nodes, even when it would not be necessary, causing the performance regression.

          Fixed. Let us know if you still see a problem, but perf should be roughly equivalent now.

          Show
          Edson Tirelli
          added a comment - Thanks for reporting. The problem was that the new parser was generating a slightly different Descr AST for the accumulate statement, which in turn was forcing the ReteOO builder to create subnetworks for all accumulate nodes, even when it would not be necessary, causing the performance regression. Fixed. Let us know if you still see a problem, but perf should be roughly equivalent now.

            People

            • Assignee:
              Edson Tirelli
              Reporter:
              Roman Novak
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: