Readability vs Performance

问题:

Recently we had a discussion at work about the impact of local variables on the performance vs readability of Java code. Some of my colleagues are of the oppinion that declarations like this

new DoSomethingCmd(new SelectionContext(context, keys), infoStuff.getCurrentRole().getRole_id()).execute(getResultContainer());

will give the application a considerable performance boost. They are willing to sacrifice code readability for this. Are they right in claiming this? Is the above version significantly more performant than, say, this one?

final SelectionContext selectionContext = new SelectionContext(context, keys);
final String roleId = infoStuff.getCurrentRole().getRole_id();
final DeleteSomethingCmd deleteSomethingCmd = new DeleteSomethingCmd(selectionContext,roleId);
deleteSomethingCmd.execute(getResultContainer());

I realise that the first statement isn't all that difficult to grasp in and on itself, but the complexity adds up rather quickly when most of your code is structured like that.

Thank you for your input.

回答1:

The only thing that the "optimized" version makes is that you have a few variables less in the stack, slightly increasing your memory consumption. Performance should be measured carefully (google how to benchmark an issue), but I seriously doubt that it has any noticeable effect.

Also, spending time improving performance in a piece of code that is not used often is just a waste of developer time, which is expensive.

In this case, readability should win the day.

EDIT: Anyway, if you use proper indentation, I do not thingk the two versions are too different in readability terms:

new DoSomethingCmd(
    new SelectionContext(context, keys),
    infoStuff.getCurrentRole().getRole_id()
    ).execute(getResultContainer());

The advantage of this text is that you do not have defined variables (selectionContext, roleId)that are no longer needed (so when you read the method again they do not mix with more "persistent" variables). Anyway, that is open to interpretation; the bottom line is that you should not worry with optimization unless you have a motive to do so.

Apart from that, there are some guidelines to Java programming that give you really useful tricks that really help you (v.g. using StringBuilder to concatenate strings).

回答2:

Are they right in claiming this?

No, they are not. The cost of storing something in a local variable and then subsequently reading from it is next to 0, it's as simple as that -- this is definitely not something that you should spend your time optimizing, or even worrying about for that matter. Don't sacrifice readability by putting everything in a single, highly convoluted line.

回答3:

A person's time is millions of times more expensive than a computer's time.

If the line of code is expected to execute millions of times more than it will be looked at by a programmer then perhaps you should consider optimising. But certainly not until then.

Even then, it is completely pointless to optimise as if the compiler is stupid.

Don't forget! Premature optimization is the root of all evil.

回答4:

I see several function calls in here

• two calls to new

• a SelectionContext constructor

• a call to getRole_id()

• a DeleteSomethingCmd constructor

• a call to GetResultContainer()

• a call to the execute() member of the deleteSomethingCmd

So suppose you run this a gazillion times, and in that time you take some stack samples.

What do you think is the probability that a stack sample does not show you inside one of those function calls?

Extremely low, right? Probably far less than one percent?

So even if you made the code at this level infinitely fast, what would it save you?

Perspective is everything.

回答5:

The first version is mot much more performant than the second. I doubt you can reliably measure the performance difference. Moreover, after jit optimizations, the result machine code should be the same.

回答6:

Strictly speaking to the examples, no, there is no measurable difference (not on a modern system, anyway) between the two. However, it is very true that you can get significant performance increases by writing a lot of lower level code to do what can be done with less code at a higher level. For instance, working with arrays is faster in many cases than using any of the Collections API (maybe not much, but it is). But you lose not only readability, but maintainability as well by doing so and usually for an insignificant increase in performance.

Code should always be well organized and readable. Only after getting good performance metrics should you go and look at giving that up for the performance increase.