[ http://jira.codehaus.org/browse/DROOLS-446?page=all ]
Michael Neale resolved DROOLS-446:
----------------------------------
Resolution: Fixed
done
> Performance degradation due to PrimitiveLongMap
> -----------------------------------------------
>
> Key: DROOLS-446
> URL: http://jira.codehaus.org/browse/DROOLS-446
> Project: drools
> Type: Bug
> Components: reteoo
> Versions: 2.1, 2.0-final
> Environment: JDK 1.4.2_08
> Reporter: Jerry Cattell
> Assignee: Michael Neale
> Priority: Critical
> Fix For: 2.5
> Attachments: DroolsPerformanceExample.java, WorkingMemoryImpl.java,
> odds.java.drl
>
>
> I am experiencing performance problems using drools with a very simple use
> case. I have 50-100 rules, 5-10 facts, and assert facts and fire the rules
> hundreds to thousands of times per second. I have attached a basic example
> of the problem I am encountering. You'll see that as it loops, creating new
> WorkingMemory objects, asserting facts, and firing rules, the time to do this
> takes longer and longer until it gets to an unusable state.
> After running this through JProfiler, I found the hot spot to be
> PrimitiveLongMap. When the RuleBase is cached and new WorkingMemoryImpls are
> created (as the preferred approach seems to be), the generated FactHandle ids
> continue to increase. The problem is that as the number gets large, say over
> 1 million, the PrimitiveLongMap seems to spend all of its time creating
> Pages, or alternatively, iterating through all of the pages to return the
> collection of values when WorkingMemoryImpl.getObjects is called.
> I was able to fix this for my use case by simply replacing PrimitiveLongMap
> with HashMap. Of course, I'm assuming PrimitiveLongMap was used to replace a
> HashMap for a reason (very large number of facts? Long object creation?), so
> this is probably not a long term solution for the drools project. So I see
> three other options:
> 1. Fix PrimitiveLongMap. I haven't spent the time to try and understand what
> type of work this would require.
> 2. Replace PrimitiveLongMap with a different implementation (perhaps one of
> the ones listed on
> http://blogs.codehaus.org/people/mproctor/archives/000890_primitive_map_implementation_and_benchmark_comparisons.html
> ).
> 3. Generate fact handle ids on a per working memory basis (as shown in the
> WorkingMemoryImpl.java included). I don't know if the RuleBase ever uses the
> FactHandle id in a global way or always just passes the FactHandle object
> through to a WorkingMemoryImpl, so that could lead to potential problems.
> Let me know if any additional details are required.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
