Java Strings: private static vs local variable performance
Asked Answered
C

3

24

Is there any performance benefit by using a private final static String in java vs using a local string variable that has to get "initialized" every time the method is accessed?

I do think that using private static final strings is a good practice for constants that get reused in different parts of a class, however if a string were to be used only in one method, in one location, for a very specific reason that no other method is concerned about, I actually prefer to keep the class' internal interface clean with less private members, and just use a local variable.

Given that java has String interning, and actually keeps a pool with a single copy of each string that gets declared using quotes (String s = "some string"), would there actually be a performance hit from having to declare / initialize / assign the variable each time the method is accessed vs using a static string?

To make it a bit more clear, would there be any difference between using SS or LS?

class c {
private final static String SS = "myString";

  private void method(){
     //do something with SS
  }

  private void OtherMethod(){
     String LS = "myOtherString"
     //do same thing with LS
  }
}
Chicago answered 23/3, 2016 at 18:5 Comment(2)
"keeps a pool with a single copy of each different string" this is incorrect. The only strings Java interns (unless you call String.intern()) are "quoted" constants in your code. Strings constructed at runtime are not interned in the constants pool.Glycol
you are right, those where the ones I was referring to, I'll editChicago
G
11

Using a named constant is likely to be better for maintainability. However constants known at compile time can be used as inline in which case there is unlikely to be any difference.

Note: if you are using a String literal, this will be created just once, no matter where in the JVM it is used.

In this case the only difference is using a local variable on the stack which is unlikely to be any more expensive than a constant which have been used as inline.

would there actually be a performance hit from having to declare the variable each time the method is accessed

As Java uses a static compiler, a variable is only declared once (or once for each stage of compilation), when loading the class/method, regardless of how many times the methods is called. The variable might be initialized each time however.

Glasswork answered 23/3, 2016 at 18:20 Comment(0)
R
4

The truth is, at the end, there is no difference. A constant string in a local variable will still end up in the constant pool and optimized. So generally speaking, local variables are faster because they are easier to access, but in the case of constant strings it does not make a difference. So choose whatever is more readable and intuitive in your case.

Rework answered 23/3, 2016 at 18:10 Comment(4)
@Xoce웃Пepeúpa a local variable is likely to be slightly faster than accessing a non-final static field. However constants can be inlined so the difference is notional.Glasswork
a lokal variable can be very well optimized. in some cases it can be eliminated. in others it can be accessed using very fast instructions that work relativ to the stack or base pointer. static variables must always be accessed using their full addressRework
It isn't a local variable though. It is stored only in the constant pool and loaded through a ldc instruction, which is very close in timing to a getstatic.Homemade
in theory, but its a totally different story after JIT compilationRework
M
0

I guess creating constants comes from old time when creating statics helped in maintaining only one string as part of the class in the jvm, rather than the object which gets created and garbage collected every time the object is created and destroyed. But with spring default scope as singleton rather than prototype, I guess it makes no difference. So, yeah, it depends how the class will be used, is the answer.

Macrocosm answered 15/9, 2022 at 9:15 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.