JBRULES
  1. JBRULES
  2. JBRULES-2982

Massive performance degradation from 5.2.0.M1 to 5.2.0.M2

    Details

    • 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

        Gliffy Diagrams

          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:

                  Development