we jarjar asm to prevent collisions with other versions of ASM. for
instance, the previous ASM will not work with the latest one (they have
not made it backwards compatable) - API changes all over the place. It
is also a small library, so its OK to do this (and the licence allows
it). It also means that we can in theory run the runtime (core) with no
external dependencies, once we inline the jarjared ASM.
asm is used in lots of things - for isntance if anyone was using certain
versions of hibernate, or websphere, if we did not jarjar ASM drools
would simply not work.
Definately looks like something we can use, should be a more efficient
approach as there is no switching going on (just get the value directly).
I need to have a look at it with jprofiler (with reteoo), but don't want
to get too distracted from the 3.0 beta going out at this time (but I
will get to it). As I know, once I start, I won't be able to stop !!
Strange that manners isn't faster, as it was showing up at the top of
the list. More research needed I think.
Thanks though ! Thats pretty cool - looks like exactly what I was
thinking ! Awesome.
How is leaps going in general?
------------------------------------------------------------------------
*From:* Alexander Bagerman [mailto:[EMAIL PROTECTED]
*Sent:* Sun 12/03/2006 6:32 AM
*To:* Michael Neale
*Cc:* Mark Proctor
*Subject:* New ClassFieldExtractor
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
>
