Re: [Ikvm-developers] Overhead and Best Practices

[Mark P. <li...@ma...>]

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
>
>