IG and Move improvement: Move utility method closer to consumer, when used by only 1 user/tree/package

This sort of thing has been on my list, but I had assumed it would take global analysis, or would be too slow for interactive use. I'm going to be revisiting that assumption. I've got a feeling that this case is doable, but more complex move suggestions (package split, package merge, module split/merge, multi-class moves) aren't doable with the current API.

--Dave Griffith

Dave

>..I had assumed it would take global analysis, or would be too slow for interactive use.
>

From my tests around @TestOnly, it's usable for interactive - editor
highlights -, but way too slow for the explicit inspection of a full
project.
It requires inspecting checking every class, method and field of the
project. If basic conditions are matched - static, not private, ..- you
then have to obtain the references to the member, and that operation is
the killer: it takes 50-100 ms/call.
See

http://www.intellij.net/forums/thread.jsp?forum=23&thread=144610&tstart=0&trange=100#4872694

Alain

Right. To do that we would need a global inspection API, which would let me create the reference batch forward, rather than backward, by looping over all the files and resolve()ing. MetricsReloaded already does this for cycle-finding, and it's reasonable if not great. If we had that, then all of the move-suggestion inspections become pretty straightforward.

--Dave Griffith

Dave

>Right. To do that we would need a global inspection API, which would let me create the reference batch forward,
>

Why would that be faster? Think of a huge project with only 1 utility
class, with only one non private static method.
The 'backward' algorithm would have you use findReference() only once
for the whole project.



Alain

It wouldn't be faster for one class, but the total runtime would be much faster for all classes. This is clearer in the package cycle implementation or the built-in dead code elimination. You have to build all paths, and for that iterating through the PsiClasses and doing "resolve()" on every reference is much quicker than doing "findReferences()" on each PsiClass.

--Dave Griffith

Note also that there's nothing in your problem that applies just to utility classes, other than that their methods can be moved independently. Moving arbitrary classes closer to their consumer would also be a useful capability.

--Dave Griffith