Reflection-Performance

[Datenklaun]

Hallo

Bei der Entwicklung von einer Art Interpreter bin ich immer wieder auf die Performance-Schwachstelle von Reflection aufmerksam geworden, weshalb ich mich schon mit Alternativen à la Javassist und so weiter beschäftigt habe, ohne je einen Test gemacht zu haben.
Das wurde heute nachgeholt und führte bei einem Test von Instanzierung und Methodenaufruf zu einem für mich unglaubwürdigen Ergebnis. Daher stellt sich mir die Frage ob in meiner Testmethode ein grober Fehler steckt, den ich übersehe.

Oder kann es sein, daß das Instanzieren von Objekten und das Aufrufen von Methoden per Reflection in Java 7 schon extrem schnell ist? Wenn ja, wie ist es bei älteren JRE's?

In der Methode wird zuerst ein Frame-Object instanziert, die Methoden setTitle, show, und dispose aufgerufen und anschließend das Frame-Object wieder gelöscht. Dieser Ablauf wird durch eine for-Anweisung mehrmals wiederholt, um ein stabileres Ergebnis zu bekommen.
Der selbe Ablauf wird dann mittels Reflection nachgebildet, was jedoch zusätzlich noch das Ermitteln des Class-Objekts und Method-Objekts erfordert.

Umgesetzt habe ich das ganze so:

public Object[] test()
{

  Object[] ret=new Object[2];
  long time=System.nanoTime();

  for (int i=0;i<44;i++){
    Frame testObj= new Frame();
    testObj.setTitle("Frame 1");
    testObj.show();
    testObj.dispose();
    testObj=null;
  }

  ret[0]=new Long(System.nanoTime()-time);
  time=System.nanoTime();

  for (int i=0;i<44;i++){
    try{
      Class testClass=Class.forName("java.awt.Frame");
      Object testObj=testClass.newInstance();
      testClass.getMethod("setTitle",new Class[]{(new String()).getClass()}).invoke(testObj,new Object[]{new String("Frame 1")});
      testClass.getMethod("show",new Class[]{}).invoke(testObj,new Object[]{});
      testClass.getMethod("dispose",new Class[]{}).invoke(testObj,new Object[]{});
      testClass=null;
      testObj=null;
    }
    catch (Exception e){
    }
  }

  ret[1]=new Long(System.nanoTime()-time);
  return ret;

}

Auf meinem Windos-System ergab die Zeitmessung für die natürliche Instanzierung ca. 4 mia ns und bei der reflektiven 4.5.
Wenn ihr einen markanten Fehler findet, der den Test verfälscht, freue ich mich; wenn der Test stimmt dann kann ich jubilieren und mir (vorerst) den Umweg über Bytecode-Verarbeitung sparen.

Viele Grüße, DerKlaun

 

[mvitz]

Leider ein Microbenchmark ohne Aussage:

public class Test {
    public static void main(String[] args) throws Exception {
        long time = System.nanoTime();
        for (int i = 0; i < 44; i++) {
            javax.swing.JFrame t = new javax.swing.JFrame();
            t.setTitle("Frame 1");
            t.show();
            t.dispose();
            t = null;
        }   
        System.out.println("Instanzierung");
        System.out.println(String.format("%,d ns", System.nanoTime() - time));
        time = System.nanoTime();
        for (int i = 0; i < 44; i++) {
            Class clazz = Class.forName("javax.swing.JFrame");
            Object t = clazz.newInstance();
            clazz.getMethod("setTitle", new Class[]{String.class}).invoke(t, new Object[]{"Frame 1"});
            clazz.getMethod("show",     new Class[]{            }).invoke(t, new Object[]{         }); 
            clazz.getMethod("dispose",  new Class[]{            }).invoke(t, new Object[]{         }); 
            t = null;
            clazz = null;
        }   
        System.out.println("Reflection");
        System.out.println(String.format("%,d ns", System.nanoTime() - time));
    }   
}

führt bei mir zu:

java -version && javac Test.java && java Test
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)
Note: Test.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Instanzierung
526.264.000 ns
Reflection
384.813.000 ns
-------------------------
java -version && javac Test.java && java Test
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
Note: Test.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Test.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Instanzierung
852.282.569 ns
Reflection
222.950.540 ns

 

[tfa]

wenn der Test stimmt dann kann ich jubilieren und mir (vorerst) den Umweg über Bytecode-Verarbeitung sparen.

Hast du denn ein konkretes Performance-Problem? Wie gesagt, Microbenchmarks sind meistens ziemlich sinnfrei.

 

[SlaterB]

du testest intensive Objekte, deren Methoden wie show() solange brauchen, da macht es quasi keinen Unterschied wie sie aufgerufen werden,
wenn man einen Baum auf 30 Meter wachsen läßt und die Zeit misst, ist es relativ egal ob man zu Fuss oder mit dem Auto von der Baumschule nach Hause kam..

generell kann noch gefährlich sein, wenn Dinge anfangs initialisiert werden, ruhig den Test mehrfach laufen lassen in einem Programmablauf

new String().getClass() + new String("Frame 1")
sind unnötig langsam, das lohnt selbst als Test nicht, das kann man in der Realität nicht so buggy coden

-----

hier ein Test mit kleinen Objekten der dann Reflection entsprechend schlecht aussehen lässt:

public class Test
{
    public static void main(String[] args)
    {
        System.out.println(Arrays.toString(test()));
        System.out.println(count);
    }

    static int count = 0;

    public static Object[] test()
    {
        String x = "hi";
        Object[] ret = new Object[2];
        long time = System.nanoTime();

        int k = 44;
        for (int i = 0; i < k; i++)
        {
            Xy testObj = new Xy();
            testObj.sum(x);
        }

        ret[0] = new Long(System.nanoTime() - time);
        time = System.nanoTime();

        for (int i = 0; i < k; i++)
        {
            try
            {
                Class testClass = Class.forName("test.Test.Xy");
                Object testObj = testClass.newInstance();
                testClass.getMethod("sum", new Class[]
                    {String.class}).invoke(testObj, new Object[]
                    {x});
            }
            catch (Exception e)
            {
            }
        }

        ret[1] = new Long(System.nanoTime() - time);
        return ret;

    }

    public static class Xy
    {

        public static void sum(String x)
        {
            count += x.length();
        }

    }
}

800.000 zu 57 Mio. Nanosekunden, 700x langsamer..

je nachdem ob man lange Methoden aufruft oder kurze wird die konstante Reflection-Arbeit einen hohen oder unbemerkbaren Anteil einnehmen,

bei deinen Frame-Erzeugungen kommen bei mir Zahlen um 200 Mio. heraus, wobei es ohne Reflection nicht unbedingt schneller ist,
das ist nicht gerade logisch, vielleicht finde ich noch was dazu, jedenfalls wären etwa 50 Mio. für Reflection dort schon längst kein Faktor 700 mehr, nur noch 1.25

 

[datenklaun]

Hallo
Die Bugs sind ja wirklich unangenehm und waren komplett ungeplant. Dazu kann ich nur die Ausrede anführen, noch relativ neu bei Java und in der OOP an sich zu sein.
Danke für die Korrekturen; in Zukunft werde ich es besser machen.
Auch daß das Beispiel mit dem Frame schlecht gewählt ist kann ich nachvollziehen, andererseits finde ich es ganz interessant, daß die Performance-Schwachstelle wohl nicht für alle reflektierten Objekte ein nennenswertes Thema ist.
Danke nochmal für die Auskünfte und viele Grüße, datenklau.

 

[datenkaun]

Das Programm soll ein Interpreter werden, mit dem Java-Objekte unabhängig vom Compiler benutzt werden können, beispielsweise in einem Applet oder Midlet. Da ich das ganze vielleicht automatisieren möchte, spielt dann die Performance schon eine Rolle, damit ein solches Pseudoprogramm nicht allzusehr humpelt.

 

[theuserbl]

Möglicherweise hilft Dir auch dieses hier weiter:
reflectasm - High performance Java reflection - Google Project Hosting

Grüße
theuserbl

 

[Wildcard]

Microbenchmarks lassen sich gut mit Japex durchführen. Japex kümmert sich selbstständig um Warm Up Phase und ausreichend Iterationen um ein sinnvolles Ergebnis zu erhalten. Im Beispiel mit dem JFrame bringt auch das allerdings nicht viel, wie SlaterB ja schon erklärt hat. Der zu messende Teil verschwindet im vergleich zum konstanten Aufwand.