only reason is it is static is cause maven didn't have an easy way to do it, and it seemed like a waste to do it each time (but it is fast to jarjar ASM, for sure).
________________________________ From: Mark Proctor [mailto:[EMAIL PROTECTED] Sent: Mon 13/03/2006 4:15 AM To: Alexander Bagerman Cc: Michael Neale; [email protected] Subject: Re: New ClassFieldExtractor drools-core should have no external dependencies, so all dependencies should be inlined with jarjar/proguard - which at this point is only ASM. I'm not entirely sure why we have this done statically, with asm in repository/ rather than as part of the build system when we create the jars. Any ideas why waltz benefits but manners doesn't? I'd like a stronger understanding, performance and memory, before we make the switch. maybe you could make a very basic benchmark to profile the two systems in isolation? I'm taking this conersation to the DEV list as others may have input. Mark Alexander Bagerman wrote: Mark, Michael, I just checked in two new files BaseClassFieldExtractor and ClassFieldExtractorFactory in org.drools.base. It uses approach we discussed earlier. It does not affected performance of Manners test but brought execution for Leaps Waltz test down to 30% of what it run with previous version of ClassFieldExtractor. So, 3 times performance improvement for this case. Waltz does not run under RETEOO (I created Jira entry for it). Please check it out and let me know if it something we can use across the rest of the code. We then need to drop existing ClassFieldExtractor then. The question I have is why do we have our own copy of ASM instead of the original one? Thanks, -Alex On 3/9/06, Michael Neale <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> wrote: Yep, as per our discussions, put design notes in JIRA. Alex is going to experiment with manners and reteoo, see what the impact is. If its significant, then it is a relatively easy optimisation (probably take me a day). It will mean generating more extractor classes on demand, but thats OK. ________________________________ From: Alexander Bagerman [mailto:[EMAIL PROTECTED] Sent: Fri 10/03/2006 6:55 AM To: Michael Neale; Mark Proctor Subject: ClassFieldExtractor suggestion Michael, Mark, I 've been profiling drools and noticed that one of the areas where we can improve is ASM part that extracts field values. To benchmark it I created "hard coded" versions of ClassFieldExtractor's for Waltz example that just do casting/getAttribute calls. I attached base class for this implementation and one of the samples to this email. I gained 2.5 times in terms of the performance with this approach comparing to ASM getMethodByIndex. Michael, would it hard to implement adhoc generation of ClassFieldExtractor per my attached sample? Do you want me to open Jira to track it? Thanks, -Alex
