Acording to the fine manual, creating a working memory is a "cheap
operation"; At the same time the more object you get, the better the
efficiency of the rete network - or at least I believe so.
The second idea is probably better but why would you want to retract
the object once the computation is over? Granted, I'm not sure it does
all that much of a difference between modify() ing them and asserting
them again, but you can probably implement a propertychangelistener
specific to your needs that would fire the event once your object was
updated by another thread.
Just some early thoughts...
Dirk Bergstrom a écrit :
How much memory does a WorkingMemory consume? How long does it take to create
one?
I have a large collection of frequently updated objects, and I need use a set
of rules to process each one against a different regularly updated object.
Let's call the first objects products, and the second markets (this is a made
up example, but it's close to what I'm doing). Say I've got 200 products, and
7 markets. The product specifications change many times a day, market
conditions change a few times a day. The products must be evaluated
independently of each other (in other words, asserting them all into a single
working memory doesn't win me anything). Several of the properties on the
products are complex (based on collections of other non-time-constant
objects), and thus it won't work to put PropertyChangeListeners on them. I'll
have to modify() each product every time I update it. It takes several
seconds to update each product (lots of database calls), so keeping everything
up to date (200 products * 7 markets * 5 seconds = 2 hours) takes a while. To
add to the mess, I have two groups of products that update on different
cycles, so I need to have a different thread for processing each group. I've
got around forty rules now, but I expect that number to grow.
So given the above constraints, I'm trying to decide between two possible
implementations:
*) Have a dedicated working memory (WM) for each product/market pair. Assert
the market once, assert the product once, then modify() the product every time
it's updated from the db. This means I'll be keeping 1400 WM's in memory.
*) Every time I update a product, create a new WM, assert the market and the
product. This means I'll be creating a WM and asserting a market 150,000
times a day.
Hmm, waitaminute, I just had a better idea! Amazing what you come up with
when you write things down. Do you guys see anything wrong with this
implementation:
*) Have a dedicated WM for each market. Create the memory, assert the market
once, stash it in memory. Update a product, assert it, fire the rules, read
the results, retract the product. Now I'm only keeping seven WM's in memory,
and I'm not asserting market objects every cycle. I think this is also fairly
easy to do in a thread-safe manner.
So back to my original questions. I need to have an idea of the tradeoffs
between memory consumption and time to fully evaluate the above implementations.
I'd appreciate any feedback y'all might have on this.
Thanks.
--
___________________
*Gabriel Quennesson *| CTC/I | *SEAM*
Int :* *7 906 6910 | Ext: 04 73 64 69 10
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
