0

In regards to Java, I'm very accustomed to declaring all of my variables as private and generating public getters and setters to hold true to common convention.

I find it curious, though: in relation to getters and setters with no functionality outside of assigning and returning the requested value, is there no performance hit for calling methods like:

String getValue() {
    return value;
}

instead of:

classInstance.value;

Does the compiler do something here to help keep the function call from adding an extra cycle? If not, then doesn't this theoretical hit snowball into a large hit in more robust applications?

Edit:: For clarification, this question is not asking why you should or shouldn't use accessor methods, the question is whether or not you take a performance hit by using accessors.

anomeric
  • 688
  • 5
  • 17
  • 1
    very wide question, but generally don't use micro optymalisation, clean readability is more important. – Jacek Cz Aug 11 '17 at 14:37
  • In the scope of any sufficiently complex program, I would think the overhead is negligible – OldProgrammer Aug 11 '17 at 14:38
  • I didn't think it was too broad. Does defining a getter and setter method over using public variables add an extra cycle of work in Java? Personally, I don't think that classInstance.getValue() is any less readable than classInstance.value; – anomeric Aug 11 '17 at 14:38
  • 1
    @anomeric Well, [there are actually many good reasons to consider using accessors](https://stackoverflow.com/a/1568230/1225328). – sp00m Aug 11 '17 at 14:40
  • @sp00m Thanks for the link, but the question isn't about the reason why you should use accessors, the question is whether or not you take a performance hit. – anomeric Aug 11 '17 at 14:44
  • 1
    This really a question from another era. The things that slow programs down now are issues like database caching, multi-threading, and performance scaling – ControlAltDel Aug 11 '17 at 14:47
  • @ControlAltDel The question is not about whether or not accessors should be used. The question is whether or not a performance hit exists. – anomeric Aug 11 '17 at 15:21

2 Answers2

3

Does the compiler do something here to help keep the function call from adding an extra cycle?

Yes.

A Hotspot JIT compiler will inline short methods, and a simple getter or setter is short enough to allow that. Inlining the method body gets rid of the overheads of the parameter assembly and the method call, and allows further local optimization in the context of the calling method.

The net result is that using getters and setters is not a performance hit on a modern JVM(tm)

(Some early Android compilers didn't do this, but this has been rectified.)

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

I don't know if Java does something like that, but C++ can inline that sort of stuff.

I also like to use getters and setters, but they are slower than plain variables.

So go with getters and setters if you're creating an API and choose public variables if you need performance and readability is not that important.

eliaspr
  • 302
  • 3
  • 15
  • impossible to say getter is slower, JMV optimise when code is highly executed – Jacek Cz Aug 11 '17 at 14:44
  • I once did an experiment to find out, which showed that getters and setters were slower. But that may have been improved. – eliaspr Aug 11 '17 at 15:13
  • 1
    If your experiments showed a measurable difference for any recent version of Java, there is most likely a problem with your benchmarking techniques. – Stephen C Aug 11 '17 at 15:32