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

Question

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.

Solution 1

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

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

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

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.

View more solutions

Comments

[Gray]

Yeah the RUNTIME retention is required. And it definitely is a problem with looking up the annotation methods at all and not what I am doing with it.

[Gray]

Thanks for this @candrews. I'm not 100% sure that the issue you list is specifically at fault but it is certainly close. Looks like Method.equals() is the real culprit. I've commented on the bug.

[Gray]

Just got confirmation that the issue is indeed at fault. Thanks again @candrews.

[Gray]

Wow, really! I specifically talking about how gross Method.equals() was in the other bug report.

[user931366]

Yeah, still an issue. So, thinking I was smart, I was just going to call Method.invoke directly on my annotation since I saw the code there dove right into a native method. Well it turns out that native method eventually calls AnnotationFactory.invoke() which leads to yet another Method.equals() call. Can't think of any other work arounds ATM.

[Gray]

In ORMLite I used reflection to poke down into the Android classes. Makes things 10x faster but it requires hand tuned code: ormlite.svn.sourceforge.net/svnroot/ormlite/ormlite-android/‌​…

[user931366]

Thanks for the tip Gray. Updated above with a solution that's working great for me. I didn't see your solution calling "validateValue" so I'm guess your solution is only for checking for the presence of annotations and retrieving actual values from annotation members?

[Gray]

My solution is specific to my annotations. I bypass the Android annotations entirely. I've not done a performance run but it should be significantly faster.

[Jonathan Perlow]

I think there are still major problems. I just filed code.google.com/p/android/issues/detail?id=43827

[Gray]

+1 Good generic solution. I'm a little surprised that you didn't give me (or ORMLite) credit for the solution in the code. I would have.

[spy]

this saved me countless hours. everyone on this thread rocks!