Why was "Avoid Enums Where You Only Need Ints" removed from Android's performance tips?

Question

The section "Avoid Enums Where You Only Need Ints" was removed from the official developer documentation. (See Why doesn't Android use more enums? for the old section content)

Why? Was there a change in the Android VM that made the tip obsolete?

Gudrunguelderrose

Great question, well spotted. I have avoided using enums in my code specifically because of the performance recommendation that used to be in the docs. – Maddocks

For reference, here is the decompiled bytecode for the Shrubbery example: https://gist.github.com/847418 – Flatus

As of March 2014, the following page still contains advice against using enums: developer.android.com/training/articles/memory.html#Overhead – Hypercorrect

A year later, as @TahirAkhtar said, the official Android training still says "You should strictly avoid using enums on Android." – Kianakiang

Interesting to note the recommendation to avoid enum is in this 2015 article from a lead Android developer: medium.com/google-developers/… Also: "Note that using the @IntDef annotation, which is supported by Android Studio and Gradle 1.3+, will give your code build-time type safety (when lint errors are enabled), while retaining the size and performance benefits of using int variables." – Perce

As of April 2018, the following page no longer contains advice against using enums. developer.android.com/topic/performance/memory#Overhead – Hungary

Answer 1

The 2011 answer from Elliot Hugues said that the original reason to avoid enum was for performance reason... as in "processing performance". As this reason was not backed by fact, it was removed from the official documentation.

It has been added later on because enums add a lot more data in memory than using integer.

Gudrunguelderrose

In addition Google guys introduced IntDef annotations, which allow to use int constants safely with the Android Studio errors and warning. blog.shamanland.com/2016/02/int-string-enum.html – Paleontography

Answer 2

the original version of that document was just a bunch of prejudices. it's been rewritten to only contain facts backed up by actual benchmarks, and it's updated as the VM is updated. you can find the various benchmarks -- plus some of the benchmarks we use to optimize the core libraries -- at http://code.google.com/p/dalvik/.

Chamaeleon

It would help if you listed your credentials in your SO profile. It took me some digging around. But now that I see that you seem to work on the VM team, I'll accept your answer as the official answer. :) – Gudrunguelderrose

@Elliott Hughes - it means that thesis about Enums can't be proved, or it is false? – Mischief

Adding an enum class does of course mean that your app contains an extra class, so it's not free, but we have to assume that a developer is only adding enums where they're useful. The only really bad use I've seen of enums was in some harmony code where they really wanted ints (for bitmasks and the like) and the "enum" wasn't an enum in any reasonable sense. If you find yourself calling "ordinal()" a lot, that's probably a bad smell that means you don't want an enum. But that's not an Android-specific tip, and it's a really rare design error anyway. – Chamaeleon

Is this document out of date as well @Thierry-DimitriRoy? Specifically, You should strictly avoid using enums on Android. – Busoni

FWIW, Proguard will transform enums into ints by default. – Bestow

The link you gave is dead. – Whither

@JacobTabak As of April 2018, that document no longer advises against using enums. – Hungary

Answer 3

A guess:

• Gigahertz CPUs like Hummingbird and Snapdragon are now common, and the small-code small-memory requirements which originally constrained the Dalvik VM are no longer as true.
• Every shipping device uses the JIT (new to 2.2). The enum’s class initializer will run faster, the values might be treated as JIT-time constants, and the JIT might well have special support for streamlining enum classes.
• Code which is really performance-sensitive uses the NDK, which was still new and unpolished when Android 1.5 was released. The NDK in 2.3 supports native activities, which allows for near-fully unmanaged games.

Thus, for the comparatively mundane requirements of a GUI app, the development-time benefits of enums far outweigh the extra runtime cost.

Flatus

Answer 4

Elliott Hughes offers more details about the documentation rewrite on his blog: http://elliotth.blogspot.com/2010/09/java-benchmarks.html

The second half of the post explains that every claim on the Performance doc is now backed up with benchmarks. Previous versions of the doc apparently contained unverified claims, like, "Avoid enums because they are too expensive."

Cinereous

Just wanted to supplement Elliott's accepted answer with this link. – Cinereous

Answer 5

TLDR: Dalvik was not good with memory allocation and Enum uses more memory than int. Android Lollipop replaced Dalvik with ART which does not suffer from the same limitations. Thus this recommendation is not relevant anymore.

The long answer:

Wow! 8 years, 5 answers and many comments later the real reason is still not addressed.

In the pre-lollipop Android days, Dalvik was the process VM used. As small amount of memory was available for applications to use during that time, Dalvik had a lot of memory-constraints. For memory allocation Dalvik had to walk the heap and find space. Heap would also get fragmented over time. Dalvik could not defragment, so it would allocate over time and eventually run out of space.

Avoid Enums Where You Only Need Ints

comes from Dalvik days because an Enum is a lot bigger than an int and memory allocation was very expensive.

Fast-forward today, Dalvik has been replaced by ART. ART came out in KitKat and is default since Lollipop.

ART was created from the ground up not to optimize for memory but to optimize for performance. It is also optimized for allocations and collections. The reason is it has memory set aside for large objects. Instead of putting everything in the same heap, and then having to find space for large objects amidst all the tiny ones, ART puts all the large objects and bitmaps in a separate heap. And then the small objects go in the separate heap. Also it can defragment.

After ART, if you use Enum Android does not care and this is why the recommendation is gone now.

This is coming from Chet Haase at Google. I recommend finding his Google I/O talk and watch the whole video. It contains a lot of useful information and insight into Android.

Tahoe

For reference, this is where they say it officially: youtu.be/IrMw7MEgADk?t=851 – Unreeve

Answer 6

It is still bad for memory performance.

https://developer.android.com/training/articles/memory.html#Overhead

EDIT: Now it is removed. Safe to use enums.

Sadesadella

The warning was withdrawn. – Estelaestele