0

In Java there can be two ways to call a method:

Instantiating and storing the object before calling the method.

Foo foo = new Foo();
foo.method();

Instantiating and directly calling a method

new Foo().method();

For cases where you would end up using foo again it makese sense to go with the first approach.

However, let's say we know that atleast for the current requirement foo is only used once to call method and never again. Which of the options is more suited and why?

I understand that the response can be very subjective, hence I am not looking for reasons such as shorter code, readability, etc (feel free to add them if you want to though). Instead, I am primarily looking for arguments based on performance, memory requirements, garbage collection, etc even if the difference is negligible.

This question has been asked before however I couldn't find any that discusses the above arguments.

kernel0707
  • 314
  • 2
  • 11
  • If this is the typical use of the method, then maybe `Foo` should be a singleton. Or perhaps `method()` should be static. – ernest_k Jul 15 '20 at 11:06
  • There is essentially no performance difference. Choose for readability. – Andy Turner Jul 15 '20 at 11:07
  • @ernest_k I am considering a general case here. I don't care if Foo is singleton or not or whether the methods are static. But for the sake of argument lets assume it to be non-static and non-singleton. The constructor can be parameterized as well. I am talking about a specific case where lets say it is used just once. – kernel0707 Jul 15 '20 at 11:12
  • @AndyTurner I felt that since the object is never stored in a variable it would effect the garbage collection and memory space. The amount might be negligible but a minor improvement nevertheless. Just an assumption, I can most definitely be wrong here. – kernel0707 Jul 15 '20 at 11:14
  • 2
    @kernel0707 there is a difference in the bytecode, insofar as there is an additional instruction in the first case to store in a variable. However, it is important to remember that the JVM doesn't have to execute the bytecode verbatim: if it sees an unnecessary variable assignment, it can skip it. JVMs are pretty smart: don't try to second guess what will be better. – Andy Turner Jul 15 '20 at 11:31

1 Answers1

0

I am primarily looking for arguments based on performance,

There is no difference. This local variable is essentially "free". If the method is called frequently, the JIT compiler will optimize the local variable away In any case, rhe object was just created, so its reference is in the first level cache

memory requirements,

If the optimizer doesn't remove it, a local variable may occupy a few extra bytes of space on the thread call stack. This space is reclaimed and reused when the method returns, if not sooner.

garbage collection,

The GC usually doesn't collect objects if there is a local variable pointing to it from a stack frame in a live thread. For long running methods, this may be significant: using a local variable means the object will be alive longer. For short running methods, there's virtually no difference.

etc

With a local variable, you can set a debugger break point on either of the lines. This allows you to inspect the state of the object after its creation and before the method call. Without a local variable you would have to dig deeper:

Foo foo = new Foo();
foo.method();

even if the difference is negligible.

If you're running in interpreted mode (as opposed to compiled to compiled to native), the execution of the local variable write and read (astore and aload byte code instructions) may be measurable.

Joni
  • 108,737
  • 14
  • 143
  • 193
  • 2
    I don’t think that the store and load of a single variable will be measurable, not even in interpreted execution. And, as you said, the JIT can eliminate such variables or limit their scopes, so garbage collection may be possible. Just to recall, in an unoptimized execution, the `Foo` instance can’t get garbage collected while the `method()` is executed, as the object is available through the `this` reference within the method. In an optimized execution, neither reference hinders garbage collection when the object’s memory is not needed. – Holger Jul 15 '20 at 12:38