Many thanks for the great reply. My apologies, I should made it clear that the loading of the facts is done when no rules are present. (We load the facts and then load the rules--or at this point a single rule--and the rule loading occurs without undue delay).
I quickly tried calling the parser directly (through the Jesp object) and it had the same slow performance. Then just as I was starting to write this message a thought occurred to me and I can now say that the problem is running Jess inside the Eclipse debugger. If I run the same app outside of the debugger the load time is less than a second not 30 seconds. Needless to say that has me equally baffled and presents a very real problem for using Jess if I can't figure out why it and Eclipse aren't playing nicely together. Of course, that may well just be an Eclipse problem and I am using a 3.0 build which means it's technically a Beta. I'll do some more experimenting and see if I can report back anything more insightful about why this is happening. In the meantime, has anyone else had any performance problems with Eclipse and Jess? Thanks, Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 8:00 PM To: [EMAIL PROTECTED] Subject: Re: JESS: Embedded executeCommand() performance problem I think Douglas Pearson wrote: > The problem is that loading a list of about 2,000 facts this way is > taking 30 seconds and I'm just wondering why? > > For debugging we dump the same commands to a file which we can then > load into a standalone instance of Jess through the (batch <file>) > command and there loading the same list of facts takes less than a second. Most people new to Jess don't realize that all the actual computation -- deciding which rules apply, and in what order they should fire -- happens during calls to assert, retract, and modify. The amount of work these functions have to do depends on the Rete network, which is compiled from the rules in the system. You can assert hundreds of thousands of facts per second if no rules are defined. Once you add rules, it can slow down. How slow it gets depends on how the rules are written. Chapter 10 of the manual, and chapter 8 of the book, goes into a lot of detail on this topic. So anyway, my suspicion is that the performance difference has nothing to do with either the embeddedness or the use of executeCommand(), but rather that the two installations contain different sets of rules. 2000 asserts in 30 seconds is very slow, so there's definitely at least one rule with quadratic or worse performance that could stand to be improved. > > Now, obviously we could (and probably will eventually) move to call > Rete.assertFact() instead of executeCommand() and I assume the > performance will improve. There should be virtually no difference. Everyone always seems to think parsing the code is slow. It's not, really. The Eclipse plugin we're developing uses Jess's regular parser for syntax highlighting, completion, and intention actions, and it can parse an entire large source file after every keystroke, in real time, with no noticeable delay. > The other question is whether there's an equivalent function to "batch" > that's available in the API so we could load the commands from a file > as presumably that would be fast again. You can, of course, say "executeCommand("(batch ..." If you want to get fancy, you can use a Funcall object (manual section 4.6), or use the parser directly. This one-liner: Rete engine = ... FileReader reader = ... new Jesp(new FileReader(reader, engine).parse(false); will parse and execute a file. --------------------------------------------------------- Ernest Friedman-Hill Science and Engineering PSEs Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov -------------------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
