Good to hear you've evaluated the others and didn't just assume a custom
implementation would be better. :)
> LinkedHashMap combines a HashMap and a LinkedList, that just blows
> for put/remove and uses twice as much memory.
Ouch. I am currently using a LinkedHashSet (which uses a LinkedHashMap)
for a stressy tabulist in Taseree (Tabu Search with Rule Engine
Evaluation - under ASL on SourceForge - it uses drools for evaluation,
but tabu search to solve scheduling problems). In time it seems I 'll
also have to look into optimizing it.
Thanks for the info.
Edson Tirelli wrote, On 2006-11-07 1:05 PM:
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
--
With kind regards,
Geoffrey De Smet
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
