Why are annotations under Android such a performance issue (slow)?

JavaAndroidPerformanceGarbage CollectionAnnotations

Java Problem Overview


I'm the lead author of ORMLite which uses Java annotations on classes to build database schemas. A big startup performance problem for our package turns out to be the calling of annotation methods under Android 1.6. I see the same behavior up through 3.0.

We are seeing that the following simple annotation code is incredibly GC intensive and a real performance problem. 1000 calls to an annotation method takes almost a second on a fast Android device. The same code running on my Macbook Pro can do 28 million (sic) calls in the same time. We have an annotation that has 25 methods in it and we'd like to do more than 50 of these a second.

Does anyone know why this is happening and if there is any work around? There are certainly things that ORMLite can do in terms of caching this information but is there anything that we can do to "fix" annotations under Android? Thanks.

public void testAndroidAnnotations() throws Exception {
	Field field = Foo.class.getDeclaredField("field");
	MyAnnotation myAnnotation = field.getAnnotation(MyAnnotation.class);
	long before = System.currentTimeMillis();
	for (int i = 0; i < 1000; i++)
		myAnnotation.foo();
	Log.i("test", "in " + (System.currentTimeMillis() - before) + "ms");
}
@Target(FIELD) @Retention(RUNTIME)
private static @interface MyAnnotation {
	String foo();
}
private static class Foo {
	@MyAnnotation(foo = "bar")
	String field;
}

This results in the following log output:

I/TestRunner(  895): started: testAndroidAnnotations
D/dalvikvm(  895): GC freed 6567 objects / 476320 bytes in 85ms
D/dalvikvm(  895): GC freed 8951 objects / 599944 bytes in 71ms
D/dalvikvm(  895): GC freed 7721 objects / 524576 bytes in 68ms
D/dalvikvm(  895): GC freed 7709 objects / 523448 bytes in 73ms
I/test    (  895): in 854ms

EDIT:

After @candrews pointed me in the right direction, I did some poking around the code. The performance problem looks to be caused by some terrible, gross code in Method.equals(). It is calling the toString() of both methods and then comparing them. Each toString() use StringBuilder with a bunch of append methods without a good initializing size. Doing the .equals by comparing fields would be significantly faster.

EDIT:

An interesting reflection performance improvement was given to me. We are now using reflection to peek inside the AnnotationFactory class to read the list of fields directly. This makes the reflection class 20 times faster for us since it bypasses the invoke which is using the method.equals() call. It is not a generic solution but here's the Java code from ORMLite SVN repository. For a generic solution, see yanchenko's answer below.

Java Solutions


Solution 1 - Java

Google has acknowledged the issue and fixed it "post-Honeycomb"

> https://code.google.com/p/android/issues/detail?id=7811

So at least they know about it and have supposedly fixed it for some future version.

Solution 2 - Java

Here's a generic version of Gray's & user931366's idea:

public class AnnotationElementsReader {

	private static Field elementsField;
	private static Field nameField;
	private static Method validateValueMethod;

	public static HashMap<String, Object> getElements(Annotation annotation)
			throws Exception {
		HashMap<String, Object> map = new HashMap<String, Object>();
		InvocationHandler handler = Proxy.getInvocationHandler(annotation);
		if (elementsField == null) {
			elementsField = handler.getClass().getDeclaredField("elements");
			elementsField.setAccessible(true);
		}
		Object[] annotationMembers = (Object[]) elementsField.get(handler);
		for (Object annotationMember : annotationMembers) {
			if (nameField == null) {
				Class<?> cl = annotationMember.getClass();
				nameField = cl.getDeclaredField("name");
				nameField.setAccessible(true);
				validateValueMethod = cl.getDeclaredMethod("validateValue");
				validateValueMethod.setAccessible(true);
			}
			String name = (String) nameField.get(annotationMember);
			Object val = validateValueMethod.invoke(annotationMember);
			map.put(name, val);
		}
		return map;
	}

}

I've benchmarked an annotation with 4 elements.
Millisecond times for 10000 iterations of either getting values of all of them or calling the method above:

     Device        Default  Hack
HTC Desire 2.3.7    11094   730
Emulator 4.0.4      3157    528
Galaxy Nexus 4.3    1248    392

Here's how I've integrated it into DroidParts: https://github.com/yanchenko/droidparts/commit/93fd1a1d6c76c2f4abf185f92c5c59e285f8bc69.

Solution 3 - Java

To follow up on this, there's still a problem here when calling methods on annotations. The bug listed above by candrews fixes the getAnnotation() slowness, but calling a method on the annotation is still a problem due to the Method.equals() issues.

Couldn't find a bug report for Method.equals() so I created one here: https://code.google.com/p/android/issues/detail?id=37380

Edit: So my work around for this (thanks for the ideas @Gray), is actually pretty simple. (this is trunkcated code, some caching and such is omitted)

annotationFactory = Class.forName("org.apache.harmony.lang.annotation.AnnotationFactory");
getElementDesc = annotationFactory.getMethod("getElementsDescription", Class.class);
Object[] members = (Object[])getElementDesc.invoke(annotationFactory, clz); // these are AnnotationMember[]
		
Object element = null;
for (Object e:members){	// AnnotationMembers
    Field f = e.getClass().getDeclaredField("name");
    f.setAccessible(true);
    String fname = (String) f.get(e);
    if (methodName.equals(fname)){
        element = e;
    break;
    }
}
		
if (element == null) throw new Exception("Element was not found");
Method m = element.getClass().getMethod("validateValue");
return m.invoke(element, args);

You mileage will vary based on use, but in may case this was about 15-20 times faster then doing it the "right way"

Solution 4 - Java

I think if you manage to change the RUNTIME retention policy, it should not be that slow.

EDIT: I know, for your project that may not be an option. Perhaps it is more a problem of what you are doing with that annotation rather than bad performance in general.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionGrayView Question on Stackoverflow
Solution 1 - JavacandrewsView Answer on Stackoverflow
Solution 2 - JavayanchenkoView Answer on Stackoverflow
Solution 3 - Javauser931366View Answer on Stackoverflow
Solution 4 - JavaMister SmithView Answer on Stackoverflow