views:

107

answers:

5

Recently, I started learning some Java. From what I've already learned about JVM it looks like JIT makes it pretty fast on operations requiring CPU cycles (i.e. calling a method) but also makes it hungry for memory. So when I need same output from same method as before, is it generally better approach to store the output from before in variable and use it again - while holding it in memory all this time - or call the same method again?

+2  A: 

Creating a temporary variable is unlikely to be slower.

More importantly, though: storing the returned value in a variable increases readability and maintainability of the code. For example:

Biz nibb = getBiz();
frobnicate(nibb.foo(), nibb.bar());
galuncify(nibb.bar());

If I decide that the value of nibb.biz() should be used instead of nibb.bar(), I have to remember to replace it in two places. This problem would not occur if I had used a variable instead:

Biz nibb = getBiz();
Bar bar = nibb.bar();
frobnicate(nibb.foo(), bar);
galuncify(bar);

Also notice how the method calls became more readable.

Thomas
I don't think this answer addresses his question at all. Imagine a series of 'if age > 100, if age > 75' statements. assuming age is retrieved via a method, is doing 'if guy.getAge() > 100, guy.getAge() > 75' etc. better or worse memory/cpuwise than doing 'age = guy.getAge()' first, and using that?
SLC
The question was which approach is "generally better". CPU cycles are not usually a matter of concern in this situation, questions about speed cannot be answered without knowing the machine and the JRE, and can even then only be answered by testing, and the whole thing is just a case of premature micro-optimization anyway.
Thomas
+1  A: 

There are many factors, including personal taste, expensiveness of the method, modifications that the method does, etc.

  • For basic JavaBean/map/list get methods, I usually call twice for redability, but this is personal taste. Same thing with is something methods
  • For more expensive operations that return a value (IE URL stuff), its best to store since it's a long operation to go out to the internet, get data, and report back
  • If the method modifies ANYTHING while fetching data, I store the value
TheLQ
+3  A: 

It is better practice to hold the output in a variable rather than calling the function again. The variable is going to be held in memory as long as it requires. After that automatic garbage collection will take care of that to free it up from the memory. But if you call the function, it will eat up the memory for its activation record stack each time it gets called. So if you want your program not to be memory hungry, its better to store the result in a variable and use it wherever it is required.

Anindya Chatterjee
And if a function return a newly created object for each call that means more work for the garbage collector.
Alexandre Jasmin
Also, any and all variables within the method will have a fresh copy of them created each time. addNumbers(int x, int y) { return x+y; } will create two new variables each time the method is called (it won't be reusing old variables, it will be creating fresh ones). So if you call it twice, that's 4 variables. If you call it once and store the answer, that's 3 variables. So already, storing it is using less memory, AND less CPU because the calculation only needs to be done once.
SLC
+2  A: 

As I understand the question, it's asking which is better

Bar bar = foo.getBar();
bar.donkey();
...
bar.kong();

or

foo.getBar().donkey();
...
foo.getBar().kong();

Unless getBar is expensive, there is unlikely to be significant performance differences. Likewise, memory is highly unlikely to be a problem. Concentrate on understandability.

There are differing opinions.

I believe Martin Fowler prefers the latter. The code is independent, and presumably easier to refactor.

I'm of the opinion that refactoring serves the purpose of understandability. The former tells me that the object used in both calls does indeed have a common source, and as a bonus what it is [type]. It is generally more explicitly and, although more verbose, there is less going on.

On the other hand, you might want to turn it in to something like:

foo.donkey();
...
foo.kong();
Tom Hawtin - tackline
+1 - in the absence of evidence that the *potential* inefficiency of calling the "getter" twice actually matters, readability and correctness should treated as be more important. Bear in mind that for a simple getter can often be inlined by the JIT compiler and in that case takes only takes 2 or 3 native instructions.
Stephen C
+1  A: 

Unfortunately the answer is almost certainly "it depends". In almost all cases where the time/memory tradeoff is important, you will want to base your actions on evidence rather than intuition.

That is, measure the time and memory profile of your program using realistic data. For even relatively trivial pieces of code, it's hard to work out the relative effects on inlining, JITing, cache misses and so on.

Burleigh Bear