Juanjo et. al.:
Actually, I used OPSJ on a previous project. It only generates Java code and compiles
it the first time. After that, the .ser file is used to be sure that the .opsj file
(the text version of the rules), the .java file and the .class file all have the same
timestamp. If not, then, on-the-fly, OPSJ will stop the rule evaluation process,
serialize the objects, re-generate the .java file, recompile the .class file, and pick
up where it left off. However, it only does that on-the-fly thing with the Developer
part, not the run-time part that is distributed to the clients.
One other thing: Like Jess, there is no charge for distributed applications; meaning
you can distribute the .class file, the .ser file and the run-time engine at no charge
to user nor developer. But, as I said above, you have to distribute the Developer
part if you want it to compile on-the-fly. Fortunately, our on-the-fly part was only
on the servers not on the clients. Any rules on the clients part were downloaded from
the server as necessary, which wasn't very frequently. :-)
One neat thing about JRules; they can be run in either interpreted mode (meaning no
class file) or compiled mode. The compiled mode on my present project proved to be
about 25% faster than the interpreted mode but we didn't get the flexibility that you
get with the interpreted mode.
One last thing about JDK 1.3.1: You have to use the -server and the -o compile
options to get that kind of speed in Solaris. :-)
SDG
jco
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 29, 2001 4:35 PM
To: Owen, James
Cc: [EMAIL PROTECTED]
Subject: RE: JESS: Manners test error
Hello,
At 14:52 29/6/2001 -0400, Owen, James wrote:
> Another thing that I found interesting was that OPSJ ran even faster
> than the compiled C/C++ rulebase engines, such as Haley and CLIPS and
> ILOG Rules, on the Manners 64 and Manners 128. As I understand OPSJ,
> the reason for this is that OPSJ uses the Rete 2 algorithm which
> optimizes working memory efficiency as well as employing the Rete
> network optimization.
Also that OPSJ requires a previous compilation prior to execution.
That compilation will create both a .java and a .ser file which will
be the ones executed. This compilation time takes a while when you
have many rules. So if you add this time to the execution time, OPSJ
is not that faster (although it is very fast, that's for sure).
Moreover, this limits the possibility of adding new rule sets on
run-time to the knowledge base.
> BTW, which version of OPSJ were you using? Version 4 of OPSJ is
> supposed to be even faster than Version 3.3, which is the last version
> that I tested last year some time.
I think it must be the latest, since we bought it a couple of months
ago. But I haven't found the version number anywhere.
> One final point: I heard from Java One (Greg Barton) that JDK 1.3.1 is
> significantly faster (about 200%) on Solaris than JDK 1.3.0. However,
> the improvement on NT was not so drastic; only about 25% or so.
Interesting. I will try to upgrade the JDK and run again the test to
see if any significant improvement happens.
Regargs,
Juanjo
--
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Juan Jos� Garc�a Adeva |
| Room 1G-628A mailto:[EMAIL PROTECTED] |
| Avaya Labs Research http://www.avayalabs.com |
| 101 Crawdords Corner Road Phone: +1-732-817-6228 |
| Holmdel, NJ 0733-3030 Fax: +1-732-817-4870 |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
