Is there a performance issue using a temporary variable?

Question

I have a question about creating new object in java.

Lets say i have methos called: foo(String[] a)

I want to pass to foo a new String[] thats is only for one use what is better for

performance 1 or 2

1.

String[] a = new String[]{"a"};

foo(a);

2.

foo(new String[]{"a"});

Thanks for helping

a is only for temp use. a wont be used again in the program. — dasdasd, Jul 17 '13 at 22:52
There is *no* [applicable] performance difference. In both cases exactly *one* array object is created. Although the first example is invalid as it stands; I presume `new String[]{a}` should be `new String[]{"SomeString"}` or similar. — user2246674, Jul 17 '13 at 22:53
@user2246674 - Yeah. But with respect to the question there is `nothingAffectingPerformance()` :D — JHS, Jul 17 '13 at 22:56
Check the generated bytecode using `javap -c Class.class` that contains the call of `foo` with both approaches, measure them using your fav profiler, do a heavy stress testing on this, just to note that **there is no performance gain or lose with any of those**. — Luiggi Mendoza, Jul 17 '13 at 22:57
Most of the time code readability is much more important than slight gains in performance. This looks like a classic example of [premature optimization](http://c2.com/cgi/wiki?PrematureOptimization). — m0skit0, Jul 17 '13 at 22:59
@Junaid what if one line isn't making a `String[]`, but rather an `EightMegabyteAudioFile[]`? — gobernador, Jul 17 '13 at 23:02
@gobernador - `WrongInterpretationException` :). I commented on the basis of the question. :) — JHS, Jul 17 '13 at 23:09
@Junaid You're right. *In this case,* instantiating a few strings is trivial. However, I think it's worth noting that under other circumstances, with other object types, this could be a hefty operation. — gobernador, Jul 17 '13 at 23:11

score 9 · Accepted Answer · edited May 23 '17 at 12:05

You can check the bytecode:

1.

  public static void main(java.lang.String[]);
    Code:
       0: iconst_0      
       1: anewarray     #2                  // class java/lang/String
       4: astore_1      
       5: aload_1       
       6: invokestatic  #3                  // Method foo:([Ljava/lang/String;)V
       9: return

2.

  public static void main(java.lang.String[]);
    Code:
       0: iconst_0      
       1: anewarray     #2                  // class java/lang/String
       4: invokestatic  #3                  // Method foo:([Ljava/lang/String;)V
       7: return

The only difference is that in (2), no references are stored (astore_1) and none need to be loaded (aload_1). This will almost certainly not cause a performance difference (and you shouldn't worry about such minuscule optimizations anyway), but you might as well use option (2) if you're not going to reference a again in the program (as you mentioned in your comment) and there is no readability infringement.

I think the readability component is quite important: I would much rather create a variable to store the array (even if I'll never reference this variable more than once) than have one super-long, unreadable line. Of course, in your example, there is no issue with readability, but it's something to consider when more complicated situations arise.

Looking at the bytecodes doesn't give you a meaningful answer. The actual performance depends on how the JIT compiler turns those bytecodes into native code. Different bytecodes do not imply different native code. (Identical bytecodes do not imply identical native code either ...) — Stephen C, Jul 18 '13 at 00:26
@StephenC In this particular case, I believe looking at the bytecodes reveals that the first variant can never be JITed into something that outperforms the second variant, while the second variant *can potentially* outperform the first. Obviously, the performance difference here will likely be negligible, as I detail in the answer. — arshajii, Jul 18 '13 at 00:46
That is a plausible theory (and probably correct in this case), but it is not factually based. The JIT is a black box. It is not specified what or how it optimizes. If you want to know what *really* happens you need to examine the JIT compiler source code or the native code, not the input bytecodes. — Stephen C, Jul 18 '13 at 01:51

score 3 · Answer 2 · answered Jul 17 '13 at 22:57

Having temporary local variables can help performance if you use them to store frequently used, costly-to-calculate values. For one-shot values, they still can be a big help for naming a value and making clear its intent - and the performance cost of this will be absolutely negligible.

Having or not having a variable for storing a one-shot-value is irrelevant in terms of performance, concentrate your efforts in the parts of the code highlighted as bottlenecks by a profiler, and don't waste your time in such irrelevant micro-optimizations. And it's more important to write code that's easy to understand, remember ... "premature optimization is the root of all evil."

+1 cause I agree. Better add some delay/wait calls, and remove them later, that generates more performance improvements than you'll ever need http://stackoverflow.com/questions/312003/what-is-the-most-ridiculous-pessimization-youve-seen/3187120#3187120 — TheBlastOne, Jul 17 '13 at 23:13

score 2 · Answer 3 · answered Jul 17 '13 at 23:15

2

I don't think it's possible to answer the question definitively in a general way. Even arshajii's response showing the IL is bounded.

In your code the JIT compiler will optimize this away anyway.

The level of optimization will depend heavily on things like version, platform, implementation, and a million other variables.

... now, if you had a read fence between the two, so the jitter couldn't optimize them away, then you would have a different story.

answered Jul 17 '13 at 23:15

Chris M.

1,731
14
15

2

I'm interested, do you have a reference that says the JIT will optimise this? – selig Jul 17 '13 at 23:18
@selig - AFAIK, no such reference exists ... apart from the JIT compiler source code itself. However, it is reasonable to assume that the JIT compiler will perform *obvious, simple* optimizations ... like this. (You can also confirm this by dumping and examining the native code ...) – Stephen C Jul 18 '13 at 00:28
1

@selig - I would ask the other question. This optimization is so basic, I would need documentation to show it's not being made. :-) – Chris M. Jul 18 '13 at 00:45

Is there a performance issue using a temporary variable?

3 Answers3