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.
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.
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:
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).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.
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.
I see several function calls in here
two calls to
new
a
SelectionContext
constructora call to
getRole_id()
a
DeleteSomethingCmd
constructora call to
GetResultContainer()
a call to the
execute()
member of thedeleteSomethingCmd
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.
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.