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