Re: [Codenarc-developer] More performance improvements - options?

[Chris M. <chr...@ea...>]

After I pulled in your most recent changes...

Run times for Grails + Gradle source, with my sample set of 178 rules
enabled, the average runtime went down to ~ 70 seconds (down from ~ 75sec).
This is only from 13 runs, so not at all scientific.

I also noticed a difference in timings if I had IDEA running in the
background, for what that's worth.

Chris
-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Monday, September 12, 2011 2:24 AM
To: Cod...@li...
Subject: Re: [Codenarc-developer] More performance improvements - options?

Hi Chris,

Can you run your benchmark again with the latest codebase? I'd like to see
how these changes affect performance. Locally, I see an 8-10% improvement
from this change, but I think it will be much higher in a real-world
scenario.

Thanks,


On Sun, Sep 11, 2011 at 10:52 PM, Chris Mair <chr...@ea...>
wrote:
> Hamlet,
>
> I like the getMethodCallExpressions() option. I would prefer to keep 
> the rules independent, and adding that method to SourceCode 
> interface/impl sounds like a reasonable and clean way to do that. And, 
> as you say, we could use that same pattern for other node types as well,
if needed. Sounds good.
>
> Chris
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Sunday, September 11, 2011 4:06 PM
> To: Cod...@li...
> Subject: [Codenarc-developer] More performance improvements - options?
>
> Hi everyone/Chris,
>
> I have an idea for more performance improvements that I believe will 
> make another big difference in how CodeNarc performs.
>
> There are many, many rules that look at only MethodCallExpressions.
> Each of these rules (about 50 of them), walks the AST individually and 
> searches out these MethodCallExpressions. Most the time of these rules 
> is spent in just walking the tree, which is 95% redundant processing 
> for all the rules. It would be better if the tree were walked once, 
> all the MethodCallExpressions were collected, and then each of the 50 
> rules called with just the relevant visitMethodCallExpression without 
> re-walking the entire tree.
>
> One idea to implement this is to create a CompositeRule that has a 
> list of other rules. Then the composite walks the tree once and calls 
> the other
> (children) rules when encountered. The problem with this is that a lot 
> of logic works off rule names, and the composite has many rule names. 
> I don't see a clean way to implement this.
>
> Another idea is to create a parent class that all the MethodCall 
> visitors could extend. Then that parent class could, in a static 
> block, cache all of the MethodCallExpressions and avoid walking the 
> tree redundantly. But this is not clean because each rule is run many 
> times, once for each SourceCode object (a source file). It's complex 
> to implement, has to worry about multithreading, and uses static 
> fields on instance objects. I just don't like it.
>
> My last idea, which I think is the best solution, is to add a new 
> method to the SourceCode interface. SourceCode#getAst exists today. I 
> propose we add SourceCode#getMethodCallExpressions. Then for each 
> SourceCode object we would only walk the tree once and collect useful 
> information about the tree, and rules could get the information when 
> they need it. This is pretty clean to implement. The lifecycle of the 
> cache has the same lifecycle as the source file, which makes sense. It 
> would still need to be multithread safe, but that doesn't sound hard.
> I would write this method on SourceCode:
>  Map<ClassNode, MethodCallExpression> getMethodCallExpressions()
>
> There are other performance enhancements like this as well. I think 
> PropertyExpressions have many rules. Then as we want to optimize we 
> could just add new methods onto the interface.
>
> What do you think of these approaches?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
> ----------------------------------------------------------------------
> ------
> --
> Using storage to extend the benefits of virtualization and iSCSI 
> Virtualization increases hardware utilization and delivers a new level 
> of agility. Learn what those decisions are and how to modernize your 
> storage and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>



--
Hamlet D'Arcy
ham...@gm...

----------------------------------------------------------------------------
--
Doing More with Less: The Next Generation Virtual Desktop What are the key
obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer