Using 'Show Class Cycles'

I'm trying to understand how to use "Show Class Cycles..." (SCC)
in a meaningful way and I'm not sure I've succeeded so far.

On a relatively small project (~200 classes), SCC gives me a few
cycles. I can visualize these cycles as graphs which I think I can
interpret. A little legend on the graph itself would certainly help
understand what it represents the first time one sees it. I'd love
to see a "jump to source" behavior when clicking on nodes (or
classnames) to see why a dependency exists.

On a much bigger project (~7000 classes), I cannot get any result. The
analysis seems to be memory-hungry so I gave IDEA a bunch of
available physical memory (-Xmx1300m). It took the analysis about
5-10 minutes to finish, but then the progress dialog disappeared and
IDEA was 'frozen' with 100% cpu usage for over 1.5 hour, at which
point I just force-killed it.

Are there too many classes? If so, is there a way to restrict the number
of classes (or packages or modules) the analysis is run on?

I'd be interested in hearing other people's experience with the class
dependency cycle analysis.

Vince.




6 comments
Comment actions Permalink

where's the "Show Class Cycles ..." action - the only
thing I see in the Analyze menu is "Analyze Cyclic Dependencies ..." and It does not generate the graph that
others were showing here?

0
Comment actions Permalink

It is an action provided by Dave's MetricsReloaded plugin.

For some reason I was thinking that MR was bundled with
Irida which is why I mentioned it in this forum. Your question
made me realize it is still "just" a plugin :)

Vince.


0
Comment actions Permalink

+A little legend on the graph itself would certainly help understand what it represents the first time one sees it. +

Good idea.

I'd love to see a "jump to source" behavior when clicking on nodes (or classnames) to see why a dependency exists.

Quite reasonable. I'll see what I can do.

On a much bigger project (~7000 classes), I cannot get any result. The analysis seems to be memory-hungry so I gave IDEA a bunch of available physical memory (-Xmx1300m). It took the analysis about 5-10 minutes to finish, but then the progress dialog disappeared and IDEA was 'frozen' with 100% cpu usage for over 1.5 hour, at which point I just force-killed it.

There are some really quite hungry graph-theoretic algorithms launched by that simple "Show Class Cycle" button, but the numbers you're describing seem pretty extreme, unless your project consists of one big snarl of mutually dependent classes. I have found some optimizations and algorithmic improvements I'll be including in the next release, but analyzing large snarls is going to be an issue.

+
Are there too many classes? If so, is there a way to restrict the number of classes (or packages or modules) the analysis is run on?
+

Restrictions can unfortunately break cycles, thus potentially obliterating the information you're looking to acquire. Nonetheless, I've got some ideas...

--Dave Griffith

0
Comment actions Permalink

I have the feeling that the large snarl of mutually dependent classes is
where the real value is. If I get to a large project that has a relatively
low number of cycles, well 1- I'm lucky :) and 2- I have a much smaller
problem on my hand. OTOH a tool that would help me see the big picture of
the nasty snarl and help me decide "which cycle do I want to tackle first?"
would prove really valuable.

I agree that restrictions could "hide" quite a few cycles (probably the
nasty ones, too). But if it allowed me to detect all the other smaller, more
localized cycles then I could address those first, thus reducing the size of
the snarl and having a shot at running the analysis over the whole project.

Another question for you: currently you calculate the graph's girth, radius
and diameter. My graph knowledge is not the freshest but I tend to remember
that these are non-trivial problems and could be expensive. Are they needed
for things other than providing metrics for the users? If not, and if they
are an expensive part of the process, could they be disabled for cases like
mine? (Through an option on the dialog for exemple).

Thanks,

Vince.


0
Comment actions Permalink


Just so you know, I sat down to optimize the cycle calculation and metrics code. Turns out due to an overly ambitious bit of abstraction, calculating all of the metrics for a cycle was taking O(n4.5) time, where n is the number of nodes in the cycle. Deeply stupid. I blame the public school system, or possibly an excessive prediliction for Kentucky bourbon and punk rock while in high school. Fixing the stupidity and polishing the algorithms dropped that to O(n2*lg n), which should be comfortable if not quick for even large projects. This also raises the priority of a release, so expect a fix
pretty soon.

--Dave Griffith

0
Comment actions Permalink

At least you can't be blamed for 'premature optimization' :))

Looking forward to a new release

Vince.


0

Please sign in to leave a comment.