Re: Overhead and Best Practices

So even after the work with WeakIdentityMap it will still be orders of magnitudes slower than if we coded natively in C# - or just orders of magnitudes slower than Java?

I may have to rethink our exception handling as we wrap every execution call for generated in Drools with an Exception, which is rethrown as a runtime exception. This is because the user generated and compiled code may or may not throw an exception.

The dynamic Class Loading and GC is worrying. In Drools 3.0 we can add and remove rules; each rule dynamically compiles code. I'm not entirely sure what unloading the entire app domain means. In Drools a package has one or more rules, each package has its own dynamic ClassLoader; when a rule is removed or updated we drop and reload the ClassLoader. If we can't hack that to work, we might have to look at a native port after all :(

btw I've started to blog this information:
http://labs.jboss.com/portal/index.html?ctrl:id=page.default.blog&project=jbossrules

Mark
Jeroen Frijters wrote:

Mark Proctor wrote:
  

The exception handling area is one I was aware of. We are 
moving the internal code to be mostly runtime exceptions, 
does that help? anything we can do to help avoid hits from 
exception handling.
    

Exceptions derived from RuntimeException? At the JVM level that really
doesn't make any difference. The biggest expense is in the collection of
stack traces, but there is a lot of other overhead as well (and .NET
exception handling is slower than Java exception handling anyway).

The current version also uses a WeakHashMap (which is another area of
inefficiency BTW), but for the next version I've rewritten this to use a
custom WeakIdentityMap that doesn't use ReferenceQueue (which doesn't
work that well and makes WeakHashMap inefficient).

  

Again any more information would be 
great, what sort of speed differences  are we talking here?
    

You can't quantify it without looking at a specific scenario, but it is
really a big difference, think order of magnitude not a couple of
percent.

  

We do a lot of dynamic classloading. This involves generating 
.java code and then compiling with JCI and Eclipse JDT. We 
then load this via a custom classloader. Is this a one off 
hit, or will it continue to be slow? What sort of hit are we 
talking about?
    

It's a one time hit in terms of CPU load, but the long term memory usage
will be much higher. Oh, and in this scenario it is also important to
note that you cannot unload code in .NET (without unloading the entire
AppDomain), so there is no ClassLoader GC like in Java.

  

Also are there clear areas where performance can still be 
dramatically improved, or has all the low hanging fruit been picked?
    

Low is relative ;-) I have several improvements planned, both to
exception handling and dynamic class loading (especially the verifier
performance can be improved significantly), but these are long term work
items and not something that can be easily/quickly implemented.

Regards,
Jeroen