Calling a getter multiple times or calling once and assigning to a variable?

Question

say suppose I have class as :

public class Age {

    private int age;

    public int getAge() {
       return this.age;
    }

}

In my Main c

Answer 1

get attrs () {
    const elem = {
        'A' :   ${"[data-test='load-more-button']}
        'B' :   $$('[data-test="product-catalog-row"]'),
    }
    return elem
} 

Is it possible (at this line) to call the get() and assign it to a variable that can be passed to the funcs() rather than passing attrs = this.attr? The funcs are in the same files as the get(). What is the correct syntax?

func1(attrs = this.attr){attr.A}
func2(attrs = this.attr){attr.B}

Answer 2

The tricky part is understanding that modern JVM's do aggressive optimizations when compiling byte code based on the knowledge available at runtime.

If, for instance, a given method is not overridden in a subclass it can be treated exactly the same as a final method, allowing the JVM to inline a copy of its code in the calling method instead of explicitly doing a method call. (If conditions change, those classes are then simply considered new and hence recompiled later based on the new conditions).

This means that get/set for bean attibutes (where the values are simply stored and retreived, and not calculated) are very cheap and you should do the calls everytime and expect the JVM to detect the possible optimizations and apply them.

Answer 3

This is something that you, as the API writer, have to indicate to the caller.

In general, if you are simply returning a property, you can mark the call as a final (if you are not offering an actual interface). That should reduce the costs of calls since the compiler would be more likely to inline the function.

If the cost of calculating the property is expensive (E.g., a string lookup), document it in the JAvaDocs for that method, and indicate to the caller that they may want to obtain the value once and cache it.

Answer 4

I'll try to say with code examples what the other answer already said.

In the case you presented the call for getAge() is very very simple, and the cost of calling it is almost nothing. Don't bother with it in this case.

But if your getAge was something fancy that do lots of calculations or access IO resources, like:

public int getAge() {
   return slowService.calculateAgeByBirthDate(birthDate); // it takes 2 seconds to execute for every call
}

Then for sure it would be a good idea to cache de result and use it. Because if you call it 30 times your code will take 1 minute to complete.

Answer 5

In this case, I'd suggest don't look at performance, look at usability and code reuse. Your current implementation is the simplest of getters, one that returns an integer.

But what if somewhere down the line you store a person's birthdate and want to dynamically generate the age? If you simply call the property directly, you then are forced to refactor your code. However, altering getAge()'s internals, you can put the calculation in there, and you're done.

I'd really like programming languages to introduce a 'super-private' property / field modifier, one that basically says 'You can only access this property through its accessor'.

Answer 6

Don't bother. It's absolutely not worth micro-optimizing like this. Wait until you finish your code, then it runs too slowly, then get out a profiler and work on what the profiler tells you is the source of the problem.

Premature optimization is the root of all evil.