2

I have the method which returns java.util.Date inside the hibernate-entity class:

package ua.com.winforce.loto_partner.commons.db.entity;

@Entity
@Table(schema = "pr", name = "publice")
public class Pr {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private int id;

    @Column(name = "reg_date")  
    private Date regDate;

    //GET, SET
}

And in a method I need to create the local variable which will be hold getRegDate(); value, or to invoke that method twice. What would be more appropriate in that case? I mean, in the first case we're potentially closing the moment when GC will be triggered, but in the first we waste our time to the second method invocation.

St.Antario
  • 129
  • 4
  • 7
    This sounds like it'll be a difference of microseconds. Do you have any reason to think that such tiny performance optimizations are important in this code? – Ben Aaronson Dec 24 '14 at 11:35
  • one may argue that conceptually, this has been addressed in [How would you know if you've written readable and easily maintainable code?](http://programmers.stackexchange.com/a/141010/31260) If your peers keep complaining about your way of doing things, be it one way or another, you better change to make them feel better – gnat Dec 24 '14 at 12:54

1 Answers1

5

There are three reasons* to cache a function return in a variable:

  • You know or suspect that the function has side effects.
  • The function can return different values on every call, and you need a consistent result. Normally this is due to the function having side-effects, but it can also be due to reading volatile data.
  • The repeated function call would make the code less clear. This is the "extract explanatory variable" refactoring.

Your example doesn't appear to fit any of these cases.

* there is a fourth, but it's reserved for Doug Lea and Martin Thompson, and is arguably a combination of #1 and #2.

kdgregory
  • 5,220
  • 23
  • 27
  • 8
    There is another reason: Measurements have shown that the repeated call is causing measurable performance problems. – Bart van Ingen Schenau Dec 24 '14 at 13:00
  • `Normally this is due to the function having side-effects, but it can also be due to reading volatile data.` Isn't reading a volatile variable a side effect? It's effectively a form of I/O. – Doval Dec 24 '14 at 13:04
  • @BartvanIngenSchenau - I always find that profiling leads to more dramatic code restructuring than simply introducing a variable. – kdgregory Dec 24 '14 at 13:14
  • @Doval - Yes IO is a side-effect. In my original edit I only had two points, but then thought that someone would be sure to call me out on volatile reads. That said, I think that it's important to understand and recognize the difference between what I'll call "active" and "passive" side-effects: the former are caused by your action, the latter are caused by external action. In my experience, most concurrency bugs are a result of the latter, not the former. – kdgregory Dec 24 '14 at 13:17
  • As a general principle, anything that *looks* like a getter should act like a getter -- no side-effects; no lengthy business. If so, the call will probably be optimized anyway. Also never forget: "Premature optimization is the root of all evil." --Donald Knuth – safkan Jan 02 '15 at 23:54