Java HotSpot Enum overhead

Question

Suppose you have a "simple" enum:

public enum Day {
    SUNDAY, MONDAY, TUESDAY, WEDNESDAY,
    THURSDAY, FRIDAY, SATURDAY 
}

And then you use it somewhere:

Day day = Day.SUNDAY;
...
if(day==Day.SUNDAY) {...}

How does this compare performance wise (memory and time) with using ints?

int day = Day.SUNDAY;
...
public class Day {
    public static final int SUNDAY=0;
    public static final int MONDAY=1;
}

We have the JIT HotSpot compiler enabled along with other "standard" optimization.

Possible duplicate of http://stackoverflow.com/questions/8029040/performance-of-java-enums — crownjewel82, Jan 16 '14 at 16:37
This question is mostly academic. however, recently I encountered a 1000 ns or so overhead with interface calls; performance improved noticably when I removed the flexible interface-based code. That is HUGE! Perhaps the function called by the interface couldn't be inlined? — Kevin Kostlan, Jan 16 '14 at 16:37
@KevinKostlan profiling Java down to microsecond resolution is like trying to pin down an electron. The act of measurement itself, accounting for JIT and background noise due to other processes probably disturb things enough to make the measurement meaningless. Unless you have conducted an extremely rigorous benchmark that accounts for JVM architecture and OS scheduling vagaries, 1 microsecond doesn't rise to the level of significance. — Jim Garrison, Jan 16 '14 at 16:45
@Jim garrison: I had a "solid guessing" interface for rendering an image to a screen, in which you could insert any function, with HotSpot enabled, etc. When I re-did it without interferes (less maintainable code), it speed up considerably in frames per second. Thus this performance hit has a real application. My function was fairly expensive (100's of ns), so it was surprising that the interface overhead was a bottleneck with a real impact. — Kevin Kostlan, Jan 16 '14 at 17:06
I can hardly believe it. Are you saying that a single virtual call costs something like 3000 cycles? How many implementations were actually called (you know, monomorphic, bimorphic, polymorphic call site)? — maaartinus, Jan 17 '14 at 00:02
Don't know why either, if I encounter something in the future will have a closer look. It was fairly simple interface but not a single call. — Kevin Kostlan, Jan 17 '14 at 01:40

score 7 · Accepted Answer · answered Jan 16 '14 at 16:43

7

There may be a slight performance loss for the enum whenever you reference Day.SUNDAY, because the int constant is a compile-time constant and so can be inlined, whereas the enum constant requires a getstatic.

Comparing two ints or two references is of course identical in terms of time required, since you are comparing the references (addresses), not calling .equals().

Of course, the performance hit here is minuscule; the only reason to worry about this would be if this is in a performance-critical part of your application and profiling shows that using ints is better. The benefits of enums for maintainability and code correctness far outweigh a slight inefficiency like this.

answered Jan 16 '14 at 16:43

Russell Zahniser

16,188
39
30

Aren't ints primitives so value is compared, although both would be very cheap? Wouldn't getstatic be inlined after the 1000 or so Hotspot use criterion? – Kevin Kostlan Jan 16 '14 at 17:08
@Kevin Kostlan: `getstatic` is a static field access which is an atomic operation (reading of a certain memory location). There isn’t something to inline. Since the `static` fields of the `enum` constants are `final` the JVM might merge multiple accesses to the same field into one but there will always be one access remaining. However, the JIT optimizations work the other way: the code providing the two values you are comparing might get inlined, analyzed, and simplified until the JVM can deduce the result of the comparison from the remaining code. Then the comparison can be removed entirely. – Holger Jan 16 '14 at 18:40
Ok now I feel naive. Either way it is cheap. – Kevin Kostlan Jan 16 '14 at 20:59

Java HotSpot Enum overhead

1 Answers1