views:

236

answers:

4

i'm using enums to replace String constants in my java app (jre 1.5).

is there a performance hit when i treat the enum as a static array of names, in a method that is called constatnly (e.g. when rendering the UI)?

my code looks a bit like this:

public String getValue(int col) {
  return ColumnValues.values()[col].toString();
}

thanks, asaf :-)

Clarifications:

  • i guess that i'm concerned with a hidden cost related to enumarting values() repeatedly (e.g. inside paint() methods).
  • now i can see that all my scenarios include some int => enum convertion - which is not java's way.

so, if someone knows what's the actual price of extracting the values() array (or if it's even an issue), i'd appriciate it.

+2  A: 

As a rule of thumb : before thinking about optimizing, have you any clue that this code could slow down your application ?

Now, the facts.

enum are, for a large part, syntactic sugar scattered across the compilation process. As a consequence, the values method, defined for an enum class, returns a static collection (that's to say loaded at class initialization) with performances that can be considered as roughly equivalent to an array one.

Riduidel
yeh, i know: "premature optimization is the root of all evil". but this code is done in a Jtable renderer which gets rendered _a lot_. however, i was looking for someone who'd tell me that the compilers takes care of everything, and there're no gotchas here (like using reflection or something).
Asaf
Like Aaron says, it's by far better to store your enum entry in the table model than its index. This way, there is no lookup to do in the enum list. This is precisely the reason for the existence of TableModel, you know ...
Riduidel
+1. we're in agreement here. thanks!
Asaf
A: 

I think yes. And it is more convenient to use Constants.

Artic
Maybe more convenient during the development process but it's a maintenance nightmare.
Aaron Digulla
It depends. If code made by half-developer-half-plumper may be it is true.
Artic
I'm with Aaron. Enums are nicer than constants IMO - they provide type safety, so that you get a compile-time error if you try to use a value from one area of the code where you're meant to use another - string constants don't prevent this sort of error. Then there are the other benefits of enums, such as them being able to express behaviour.
Jon Skeet
And what about code readability?
Artic
http://stackoverflow.com/questions/1858829/static-string-constants-vs-enum-in-java-5 + http://stackoverflow.com/questions/66066/what-is-the-best-way-to-implement-constants-in-java. i'm not inventing anything new...
Asaf
+2  A: 

If you're concerned about performance, then measure.

From the code, I wouldn't expect any surprises but 90% of all performance guesswork is wrong. If you want to be safe, consider to move the enums up into the calling code (i.e. public String getValue(ColumnValues value) {return value.toString();}).

Aaron Digulla
safe in what way?
Asaf
If you use enums at the source, there is no performance loss since you won't have to do the conversion at all (or you'll at least save a method call). Also, you will get errors when you start using the enum in the wrong place.
Aaron Digulla
oh, type safety. of course.
Asaf
+1. thanks! ......
Asaf
+3  A: 

Enum.values() gives you a reference to an array, and iterating over an array of enums costs the same as iterating over an array of strings. Meanwhile, comparing enum values to other enum values can actually be faster that comparing strings to strings.

Meanwhile, if you're worried about the cost of invoking the values() method versus already having a reference to the array, don't worry. Method invocation in Java is (now) blazingly fast, and any time it actually matters to performance, the method invocation will be inlined by the compiler anyway.

So, seriously, don't worry about it. Concentrate on code readability instead, and use Enum so that the compiler will catch it if you ever try to use a constant value that your code wasn't expecting to handle.


If you're curious about why enum comparisons might be faster than string comparisons, here are the details:

It depends on whether the strings have been interned or not. For Enum objects, there is always only one instance of each enum value in the system, and so each call to Enum.equals() can be done very quickly, just as if you were using the == operator instead of the equals() method. In fact, with Enum objects, it's safe to use == instead of equals(), whereas that's not safe to do with strings.

For strings, if the strings have been interned, then the comparison is just as fast as with an Enum. However, if the strings have not been interned, then the String.equals() method actually needs to walk the list of characters in both strings until either one of the strings ends or it discovers a character that is different between the two strings.

But again, this likely doesn't matter, even in Swing rendering code that must execute quickly. :-)


@Ben Lings points out that Enum.values() must do a defensive copy, since arrays are mutable and it's possible you could replace a value in the array that is returned by Enum.values(). This means that you do have to consider the cost of that defensive copy. However, copying a single contiguous array is generally a fast operation, assuming that it is implemented "under the hood" using some kind of memory-copy call, rather than naively iterating over the elements in the array. So, I don't think that changes the final answer here.

Joe Carnahan
thanks! exactly what i wanted to know. the bottom line is that everybody says not to worry about it - which is what i'm gonna do...
Asaf
`Enum.values()` can't give you a reference to a static array. What would happen if you changed a value in it? I has to copy it each time the method is called.
Ben Lings
Good point - You could mutate the array after you get it, and so a defensive copy is needed. It would make more sense for them to give you an *immutable* collection to iterate over, but they don't do what would make sense here, do they? ;-) I'll update my answer accordingly.
Joe Carnahan
If you do find that you're getting (for some reason) a performance impact, you can always keep a local cache of the enumeration value array.
deterb