Complexity vs Performance

[robin harris]

I am evaluating code that has some very high complexity (McCabe Cyclomatic) and are difficult to test and certify. There are a large number of embedded logic paths (if, else), while and other iterative logic.
Can I break up a single method into multiple methods to make them easier to understand, without taking a performance hit? If so, how significant would method invocations be (as opposed to in line code)? (JVM 1.3 and 1.4)
Thanks,
Robin

[Jim Yingst]

Can I break up a single method into multiple methods to make them easier to understand, without taking a performance hit?
Almost always, yes. And chances are good that with the added clarity, you'll be able to make other improvements in the code that will result in significant gains. Or at least reduce the incidence of nasty bugs.
If so, how significant would method invocations be (as opposed to in line code)?
Extremely minor overall. In many cases the JIT compiler will probably do inlining for you if there's any real effect, and even without this, in probably 90-99% of your code it's just not worth worrying about. There may be a few small sections of your code where the effect is noticeable - use a profiler to see if this is the case. Don't worry about it until after you've observed it's a problem. Clarity has much higher payoffs on average, than minor optimizations do.

[Kirk Pepperdine]

Originally posted by robin harris:
[QB]I am evaluating code that has some very high complexity (McCabe Cyclomatic) and are difficult to test and certify. There are a large number of embedded logic paths (if, else), while and other iterative logic.
I'd be warry about picking this code apart if the corrisponding fan out and Demeter metrics are also out of range. IME, these three numbers often (but not always) travel together as they are an indication of the authors understanding of good OO prinicpals.