I was using both jakarta collections and javalution in 3.0.x. I
actually found that javalution gave no discernable speed increase
compared jdk utils. All these implementations do an Entry scan on put,
to check for existing keys, we don't need that as we can just add it.
LinkedHashMap combines a HashMap and a LinkedList, that just blows for
put/remove and uses twice as much memory. None of these facilitate or
make possible my composite indexing or allow me to return an Iterator
where I know the values are exact matches the the composite key, no
conflicts. And remeber this isn't a jdk util Iterator impl, where it
has to track current and next fields, because its doing removal - my
Iterator has one method "next()", it's as fast or faster (linked objects
are faster to iterate than arrays) than doing a for loop over an array.
To get a real understanding of this I invite you to look at:
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-core/src/main/java/org/drools/util/TupleIndexHashTable.java
Mark
Edson Tirelli wrote:
Geoffrey,
Mark's implementation is not a general purpose implementation. It is
a specific implementation for the engine. So, in Mark's
implementation, the map will not create additional "Entry" objects to
handle storing... Tuple and Fact are entries by themselves and are
directly added to internal map structures. This completelly avoid
internal entry wrapper creation as well as the GC cost for collect
them. Also, the iterator algorithm iterates directly over the objects
and return them, in a way we don't need to unwrap them before returning.
Also, the engine indexes the contents of its beta memory, and it is
probably the single most stressed piece of code of the whole engine.
The index is also a specific implementation for the map's key,
accepting both single and composite key indexing. So, again, a
specific implementation allowed us to rely on assertions made for the
specific implementation that were not possible on general purpose
implementations.
As Mark said, these were not the only optimizations we did, but they
helped a lot, reducing both algorithm cost and memory comsumption (and
GC time).
[]s
Edson
Geoffrey De Smet wrote:
HashMap is by definition really slow in iteration, but LinkedHashMap
isn't.
Have you tried replacing the HashMaps with LinkedHashMaps?
Of course a custom Map implementation can be optimized, but I
wouldn't be surprised if any of these:
- LinkedHashMap
- one of http://jakarta.apache.org/commons/collections/
- one of http://www.javolution.org/
might even be equally fast (or faster) and even better time predictable?
Peter Lin wrote, On 2006-11-07 1:28 AM:
interesting stuff. leaps backward chaining is powerful.
peter
On 11/6/06, *Peter Van Weert* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
http://www.cs.kuleuven.be/~petervw/JCHR/
A small performance result you guys can relate to: I think
manners128
runs in .5 second (*). One important contributing factor to this
result
is undoubtedly that JCHR is compiled and executed using a
Leaps-like
algorithm, rather than a RETE-based one, but JCHR is highly
optimized in
several other ways as well.
CHeeRs,
Peter
Footnote:
(*) negation as absence -- necessary for manners -- is not yet a
documented feature, but there is a partial implementation,
enough to run
manners
Peter Lin schreef:
> what's your rule engine? i'm curious
>
> peter
>
> On 11/6/06, *Peter Van Weert* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> Yup, I did the same. I stripped HashMap down to its bare
essence. I
> looked at the new JBoss hash-map code and I think the
general
idea is
> the same. Didn't give much performance gains though in my
case (didn't
> even include it in my release yet). That's why I thought it
had to be a
> combination of other factors.
> Oh well, not to worry, my performance is already more then
good enough.
> Will look for other ways of improving it even more.
>
> Thanks for the replies!
>
> -Peter
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
