All:
I realize that this answer is quite old, but I'm just now catching up on my Jess
Email from the first of the year. Wow! We seem to generate quite a bit of it.
Anyway, a "sort of" answer to your question agrees with Ernest: Increase your
memory and your stack. See the Java Optimization paper at Sun for further
information. My experience in the past has been that how much RAM and how much
stack greatly depends on the number of objects, the complexity of the rules, and
the complexity of the objects. What I have had to do is first run a series of
tests using increasing amounts of memory and increasing amounts of stack. It seems
that you will reach an optimization and then it will become more inefficient.
For example, if you are using small data sets and use more than 128M of RAM, you
will find that the number of objects and/or rules processed per second might
decrease because the machine spends more time managing RAM and stack than it does
processing the program. However, if you have very large amounts of data, say, on
the order of millions of objects, you will probably need lots of RAM to keep the
system from off-loading to your hard drive.
The bottom line is that you have to run your own tests on your data. The real
data, not just a small test set. The real rules, not just a few test rules. We
have also found that multi-threading the read process, the rulesets and the write
process greatly speeds up the overall process. See Sun's documentation on
threading as well.
SGD
jco
[EMAIL PROTECTED] wrote:
> Hi Norman,
> t
> Well, first remember that asserting facts into the Rete network is
> when all the pattern-matching gets done -- i.e., it's the most
> computationally intensive part of a Jess application. First you need
> to determine where the bottleneck actually is. If you have a profiling
> tool available (I like OptimizeIt!, but it's payware) use it and see
> what is slow. I would be -extremely- surprised if it were I/O code;
> it's most likely pattern-matching tests.
>
> Some possibilities:
>
> - Give Java more memory -- i.e., use the -Xmx128M -Xms128M
> switches. The Java heap has a fixed maximum size; the smaller it is
> the more time Java will spend garbage-collecting.
>
> - Use the HotSpot Server VM, not the Client VM. The Client VM is
> optimized for fast startup and GUI operations, not for computational
> stuff. I find that there's a significant (30%) difference in some
> cases, no differece in others.
>
> - Look at your rules. If your rules can be redesigned to create fewer
> partial matches, then fact-loading will go faster. This is probably
> the biggest opportunity to optimize things.
>
> - Use literal tests rather than function calls when possible -- i.e.,
> use
>
> (foo ?X&~bar)
>
> rather than
>
> (foo ?X&:(neq ?X bar))
>
> This can be a polynomial speedup because it allows Jess to optimize
> how Rete memories are indexed.
>
> - Use Jess 6, not Jess 5. There are some notable performance
> optimizations, especially if you're using much multifield pattern
> matching.
>
> One final note: 300M of facts as text will parse into at least 300M of
> data structures, not even counting the Tokens and Rete memories to
> hold them, and probably twice that. This is an enormous problem you're
> working on here!
>
> I think Gyhra, Norman (Student Assistant) wrote:
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > Hello!
> >
> > I process "large" files with (load-facts)
> > and there are some major issues regarding the
> > performance.
> >
> > Jess 5.0/5.1
> > JDK 1.3
> > Windows NT 4.0
> > Pentium III 450
> > 512 MB RAM
> >
> > A 770kB file takes 35 seconds.
> > It takes ages to load files with several MB.
> > My files are going to have 300 MB and more !
> >
> > Are there any faster possibilities ?
> >
> > Thanks for any help!
> >
> > Regards,
> > Norman Gyhra
> >
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Distributed Systems Research Phone: (925) 294-2154
> Sandia National Labs FAX: (925) 294-2234
> Org. 8920, MS 9012 [EMAIL PROTECTED]
> PO Box 969 http://herzberg.ca.sandia.gov
> Livermore, CA 94550
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
--
ttfn
IHN
Jim
---------------------------------
James C. Owen
Knowledge-Based Systems Corporation
6314 Kelly Circle
Garland, TX 75044
972.530.2895
214.684.KBSC (5272) cell
mailto:[EMAIL PROTECTED]
http://www.kbsc.com
"This above all,-- to thine own self be true;
For it must follow, as the night the day,
Thou canst not then be false to any man."
Polonius speaking to his son Laertes before departure
Hamlet, Act I, Scene iii
"NT's lack of reliability is only surpassed by its lack of scalability." -- John
Kirch
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
