Java Reflection Performance

Question

Does creating an object using reflection rather than calling the class constructor result in any significant performance differences

User · Answer

Significant  is entirely dependent on context   If you re using reflection to create a single handler object based on some configuration file  and then spending the rest of your time running database queries  then it s insignificant  If you re creating large numbers of objects via reflection in a tight loop  then yes  it s significant   In general  design flexibility  where needed   should drive your use of reflection  not performance  However  to determine whether performance is an issue  you need to profile rather than get arbitrary responses from a discussion forum

User · Answer

Yes  always will be slower create an object by reflection because the JVM cannot optimize the code on compilation time  See the Sun Java Reflection tutorials for more details   See this simple test   public class TestSpeed       public static void main String   args            long startTime   System nanoTime            Object instance   new TestSpeed            long endTime   System nanoTime            System out println endTime - startTime    ns             startTime   System nanoTime            try               Object reflectionInstance   Class forName  TestSpeed   newInstance              catch  InstantiationException e                e printStackTrace              catch  IllegalAccessException e                e printStackTrace              catch  ClassNotFoundException e                e printStackTrace                      endTime   System nanoTime            System out println endTime - startTime    ns

User · Answer

There is some overhead with reflection  but it s a lot smaller on modern VMs than it used to be   If you re using reflection to create every simple object in your program then something is wrong  Using it occasionally  when you have good reason  shouldn t be a problem at all

User · Answer

Yes  it s slower   But remember the damn  1 rule--PREMATURE OPTIMIZATION IS THE ROOT OF ALL EVIL   Well  may be tied with  1 for DRY   I swear  if someone came up to me at work and asked me this I d be very watchful over their code for the next few months   You must never optimize until you are sure you need it  until then  just write good  readable code   Oh  and I don t mean write stupid code either   Just be thinking about the cleanest way you can possibly do it--no copy and paste  etc    Still be wary of stuff like inner loops and using the collection that best fits your need--Ignoring these isn t  unoptimized  programming  it s  bad  programming   It freaks me out when I hear questions like this  but then I forget that everyone has to go through learning all the rules themselves before they really get it   You ll get it after you ve spent a man-month debugging something someone  Optimized    EDIT   An interesting thing happened in this thread   Check the  1 answer  it s an example of how powerful the compiler is at optimizing things   The test is completely invalid because the non-reflective instantiation can be completely factored out   Lesson   Don t EVER optimize until you ve written a clean  neatly coded solution and proven it to be too slow

User · Answer

Yes - absolutely  Looking up a class via reflection is  by magnitude  more expensive   Quoting Java s documentation on reflection      Because reflection involves types that are dynamically resolved  certain Java virtual machine optimizations can not be performed  Consequently  reflective operations have slower performance than their non-reflective counterparts  and should be avoided in sections of code which are called frequently in performance-sensitive applications     Here s a simple test I hacked up in 5 minutes on my machine  running Sun JRE 6u10   public class Main        public static void main String   args  throws Exception               doRegular            doReflection               public static void doRegular   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a   new A                a doSomeThing                      System out println System currentTimeMillis   - start              public static void doReflection   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a    A  Class forName  misc A   newInstance                a doSomeThing                      System out println System currentTimeMillis   - start             With these results   35    no reflection 465    using reflection   Bear in mind the lookup and the instantiation are done together  and in some cases the lookup can be refactored away  but this is just a basic example   Even if you just instantiate  you still get a performance hit   30    no reflection 47    reflection using one lookup  only instantiating   Again  YMMV

User · Answer

Significant  is entirely dependent on context   If you re using reflection to create a single handler object based on some configuration file  and then spending the rest of your time running database queries  then it s insignificant  If you re creating large numbers of objects via reflection in a tight loop  then yes  it s significant   In general  design flexibility  where needed   should drive your use of reflection  not performance  However  to determine whether performance is an issue  you need to profile rather than get arbitrary responses from a discussion forum

User · Answer

You may find that A a   new A   is being optimised out by the JVM  If you put the objects into an array  they don t perform so well     The following prints     new A    141 ns A class newInstance    266 ns new A    103 ns A class newInstance    261 ns  public class Run       private static final int RUNS   3000000       public static class A              public static void main String   args  throws Exception           doRegular            doReflection            doRegular            doReflection               public static void doRegular   throws Exception           A   as   new A RUNS           long start   System nanoTime            for  int i   0  i  lt  RUNS  i                  as i    new A                      System out printf  new A      d ns n    System nanoTime   - start  RUNS              public static void doReflection   throws Exception           A   as   new A RUNS           long start   System nanoTime            for  int i   0  i  lt  RUNS  i                  as i    A class newInstance                      System out printf  A class newInstance      d ns n    System nanoTime   - start  RUNS             This suggest the difference is about 150 ns on my machine

User · Answer

Interestingly enough  settting setAccessible true   which skips the security checks  has a 20  reduction in cost   Without setAccessible true   new A    70 ns A class newInstance    214 ns new A    84 ns A class newInstance    229 ns   With setAccessible true   new A    69 ns A class newInstance    159 ns new A    85 ns A class newInstance    171 ns

User · Answer

In the doReflection   is the overhead because of Class forName  misc A    that would require a class lookup  potentially scanning the class path on the filsystem   rather than the newInstance   called on the class  I am wondering what the stats would look like if the Class forName  misc A   is done only once outside the for-loop  it doesn t really have to be done for every invocation of the loop

User · Answer

Yes  it is significantly slower  We were running some code that did that  and while I don t have the metrics available at the moment  the end result was that we had to refactor that code to not use reflection  If you know what the class is  just call the constructor directly

User · Answer

There is some overhead with reflection  but it s a lot smaller on modern VMs than it used to be   If you re using reflection to create every simple object in your program then something is wrong  Using it occasionally  when you have good reason  shouldn t be a problem at all

User · Answer

Yes  it s slower   But remember the damn  1 rule--PREMATURE OPTIMIZATION IS THE ROOT OF ALL EVIL   Well  may be tied with  1 for DRY   I swear  if someone came up to me at work and asked me this I d be very watchful over their code for the next few months   You must never optimize until you are sure you need it  until then  just write good  readable code   Oh  and I don t mean write stupid code either   Just be thinking about the cleanest way you can possibly do it--no copy and paste  etc    Still be wary of stuff like inner loops and using the collection that best fits your need--Ignoring these isn t  unoptimized  programming  it s  bad  programming   It freaks me out when I hear questions like this  but then I forget that everyone has to go through learning all the rules themselves before they really get it   You ll get it after you ve spent a man-month debugging something someone  Optimized    EDIT   An interesting thing happened in this thread   Check the  1 answer  it s an example of how powerful the compiler is at optimizing things   The test is completely invalid because the non-reflective instantiation can be completely factored out   Lesson   Don t EVER optimize until you ve written a clean  neatly coded solution and proven it to be too slow

User · Answer

Significant  is entirely dependent on context   If you re using reflection to create a single handler object based on some configuration file  and then spending the rest of your time running database queries  then it s insignificant  If you re creating large numbers of objects via reflection in a tight loop  then yes  it s significant   In general  design flexibility  where needed   should drive your use of reflection  not performance  However  to determine whether performance is an issue  you need to profile rather than get arbitrary responses from a discussion forum

User · Answer

Yes - absolutely  Looking up a class via reflection is  by magnitude  more expensive   Quoting Java s documentation on reflection      Because reflection involves types that are dynamically resolved  certain Java virtual machine optimizations can not be performed  Consequently  reflective operations have slower performance than their non-reflective counterparts  and should be avoided in sections of code which are called frequently in performance-sensitive applications     Here s a simple test I hacked up in 5 minutes on my machine  running Sun JRE 6u10   public class Main        public static void main String   args  throws Exception               doRegular            doReflection               public static void doRegular   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a   new A                a doSomeThing                      System out println System currentTimeMillis   - start              public static void doReflection   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a    A  Class forName  misc A   newInstance                a doSomeThing                      System out println System currentTimeMillis   - start             With these results   35    no reflection 465    using reflection   Bear in mind the lookup and the instantiation are done together  and in some cases the lookup can be refactored away  but this is just a basic example   Even if you just instantiate  you still get a performance hit   30    no reflection 47    reflection using one lookup  only instantiating   Again  YMMV

User · Answer

If there really is need for something faster than reflection  and it s not just a premature optimization  then bytecode generation with ASM or a higher level library is an option  Generating the bytecode the first time is slower than just using reflection  but once the bytecode has been generated  it is as fast as normal Java code and will be optimized by the JIT compiler   Some examples of applications which use code generation    Invoking methods on proxies generated by CGLIB is slightly faster than Java s dynamic proxies  because CGLIB generates bytecode for its proxies  but dynamic proxies use only reflection  I measured CGLIB to be about 10x faster in method calls  but creating the proxies was slower   JSerial generates bytecode for reading writing the fields of serialized objects  instead of using reflection  There are some benchmarks on JSerial s site  I m not 100  sure  and I don t feel like reading the source now   but I think Guice generates bytecode to do dependency injection  Correct me if I m wrong

User · Answer

Yes - absolutely  Looking up a class via reflection is  by magnitude  more expensive   Quoting Java s documentation on reflection      Because reflection involves types that are dynamically resolved  certain Java virtual machine optimizations can not be performed  Consequently  reflective operations have slower performance than their non-reflective counterparts  and should be avoided in sections of code which are called frequently in performance-sensitive applications     Here s a simple test I hacked up in 5 minutes on my machine  running Sun JRE 6u10   public class Main        public static void main String   args  throws Exception               doRegular            doReflection               public static void doRegular   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a   new A                a doSomeThing                      System out println System currentTimeMillis   - start              public static void doReflection   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a    A  Class forName  misc A   newInstance                a doSomeThing                      System out println System currentTimeMillis   - start             With these results   35    no reflection 465    using reflection   Bear in mind the lookup and the instantiation are done together  and in some cases the lookup can be refactored away  but this is just a basic example   Even if you just instantiate  you still get a performance hit   30    no reflection 47    reflection using one lookup  only instantiating   Again  YMMV

User · Answer

Yes  it is significantly slower  We were running some code that did that  and while I don t have the metrics available at the moment  the end result was that we had to refactor that code to not use reflection  If you know what the class is  just call the constructor directly

User · Answer

Yes  it is significantly slower  We were running some code that did that  and while I don t have the metrics available at the moment  the end result was that we had to refactor that code to not use reflection  If you know what the class is  just call the constructor directly

User · Answer

Yes  always will be slower create an object by reflection because the JVM cannot optimize the code on compilation time  See the Sun Java Reflection tutorials for more details   See this simple test   public class TestSpeed       public static void main String   args            long startTime   System nanoTime            Object instance   new TestSpeed            long endTime   System nanoTime            System out println endTime - startTime    ns             startTime   System nanoTime            try               Object reflectionInstance   Class forName  TestSpeed   newInstance              catch  InstantiationException e                e printStackTrace              catch  IllegalAccessException e                e printStackTrace              catch  ClassNotFoundException e                e printStackTrace                      endTime   System nanoTime            System out println endTime - startTime    ns

User · Answer

Yes there is a performance hit when using Reflection but a possible workaround for optimization is caching the method     Method md   null         Call while looking up the method at each iteration        millis   System currentTimeMillis           for  idx   0  idx  lt  CALL AMOUNT  idx              md   ri getClass    getMethod  getValue   null           md invoke ri  null                  System out println  Calling method     CALL AMOUNT    times reflexively with lookup took      System currentTimeMillis    - millis      millis                Call using a cache of the method         md   ri getClass    getMethod  getValue   null         millis   System currentTimeMillis           for  idx   0  idx  lt  CALL AMOUNT  idx              md invoke ri  null                 System out println  Calling method     CALL AMOUNT     times reflexively with cache took      System currentTimeMillis    - millis      millis      will result in    java  Calling method 1000000 times reflexively with lookup took 5618 millis   java  Calling method 1000000 times reflexively with cache took 270 millis

User · Answer

Yes  always will be slower create an object by reflection because the JVM cannot optimize the code on compilation time  See the Sun Java Reflection tutorials for more details   See this simple test   public class TestSpeed       public static void main String   args            long startTime   System nanoTime            Object instance   new TestSpeed            long endTime   System nanoTime            System out println endTime - startTime    ns             startTime   System nanoTime            try               Object reflectionInstance   Class forName  TestSpeed   newInstance              catch  InstantiationException e                e printStackTrace              catch  IllegalAccessException e                e printStackTrace              catch  ClassNotFoundException e                e printStackTrace                      endTime   System nanoTime            System out println endTime - startTime    ns

User · Answer

Interestingly enough  settting setAccessible true   which skips the security checks  has a 20  reduction in cost   Without setAccessible true   new A    70 ns A class newInstance    214 ns new A    84 ns A class newInstance    229 ns   With setAccessible true   new A    69 ns A class newInstance    159 ns new A    85 ns A class newInstance    171 ns

User · Answer

Yes  always will be slower create an object by reflection because the JVM cannot optimize the code on compilation time  See the Sun Java Reflection tutorials for more details   See this simple test   public class TestSpeed       public static void main String   args            long startTime   System nanoTime            Object instance   new TestSpeed            long endTime   System nanoTime            System out println endTime - startTime    ns             startTime   System nanoTime            try               Object reflectionInstance   Class forName  TestSpeed   newInstance              catch  InstantiationException e                e printStackTrace              catch  IllegalAccessException e                e printStackTrace              catch  ClassNotFoundException e                e printStackTrace                      endTime   System nanoTime            System out println endTime - startTime    ns

User · Answer

I think it depends on how light heavy the target method is  if the target method is very light e g  getter setter   It could be 1   3 times slower  if the target method takes about 1 millisecond or above   then the performance will be very close  here is the test I did with Java 8 and reflectasm    public class ReflectionTest extends TestCase            Test     public void test perf             Profiler run 3  100000  3   m 01 by refelct      - gt  Reflection on X class   new   invoke  m 01    printResult                Profiler run 3  100000  3   m 01 direct call      - gt  new X   m 01    printResult                Profiler run 3  100000  3   m 02 by refelct      - gt  Reflection on X class   new   invoke  m 02    printResult                Profiler run 3  100000  3   m 02 direct call      - gt  new X   m 02    printResult                Profiler run 3  100000  3   m 11 by refelct      - gt  Reflection on X class   new   invoke  m 11    printResult                Profiler run 3  100000  3   m 11 direct call      - gt  X m 11    printResult                Profiler run 3  100000  3   m 12 by refelct      - gt  Reflection on X class   new   invoke  m 12    printResult                Profiler run 3  100000  3   m 12 direct call      - gt  X m 12    printResult               public static class X           public long m 01                 return m 11                          public long m 02                 return m 12                          public static long m 11                 long sum   IntStream range 0  10  sum                assertEquals 45  sum               return sum                        public static long m 12                 long sum   IntStream range 0  10000  sum                assertEquals 49995000  sum               return sum                      The complete test code is available at GitHub ReflectionTest java

User · Answer

Yes  it is significantly slower  We were running some code that did that  and while I don t have the metrics available at the moment  the end result was that we had to refactor that code to not use reflection  If you know what the class is  just call the constructor directly

User · Answer

Often you can use Apache commons BeanUtils or PropertyUtils which introspection  basically they cache the meta data about the classes so they don t always need to use reflection

User · Answer

Yes there is a performance hit when using Reflection but a possible workaround for optimization is caching the method     Method md   null         Call while looking up the method at each iteration        millis   System currentTimeMillis           for  idx   0  idx  lt  CALL AMOUNT  idx              md   ri getClass    getMethod  getValue   null           md invoke ri  null                  System out println  Calling method     CALL AMOUNT    times reflexively with lookup took      System currentTimeMillis    - millis      millis                Call using a cache of the method         md   ri getClass    getMethod  getValue   null         millis   System currentTimeMillis           for  idx   0  idx  lt  CALL AMOUNT  idx              md invoke ri  null                 System out println  Calling method     CALL AMOUNT     times reflexively with cache took      System currentTimeMillis    - millis      millis      will result in    java  Calling method 1000000 times reflexively with lookup took 5618 millis   java  Calling method 1000000 times reflexively with cache took 270 millis

User · Answer

If there really is need for something faster than reflection  and it s not just a premature optimization  then bytecode generation with ASM or a higher level library is an option  Generating the bytecode the first time is slower than just using reflection  but once the bytecode has been generated  it is as fast as normal Java code and will be optimized by the JIT compiler   Some examples of applications which use code generation    Invoking methods on proxies generated by CGLIB is slightly faster than Java s dynamic proxies  because CGLIB generates bytecode for its proxies  but dynamic proxies use only reflection  I measured CGLIB to be about 10x faster in method calls  but creating the proxies was slower   JSerial generates bytecode for reading writing the fields of serialized objects  instead of using reflection  There are some benchmarks on JSerial s site  I m not 100  sure  and I don t feel like reading the source now   but I think Guice generates bytecode to do dependency injection  Correct me if I m wrong

User · Answer

Reflection is slow  though object allocation is not as hopeless as other aspects of reflection   Achieving equivalent performance with reflection-based instantiation requires you to write your code so the jit can tell which class is being instantiated   If the identity of the class can t be determined  then the allocation code can t be inlined   Worse  escape analysis fails  and the object can t be stack-allocated   If you re lucky  the JVM s run-time profiling may come to the rescue if this code gets hot  and may determine dynamically which class predominates and may optimize for that one   Be aware the microbenchmarks in this thread are deeply flawed  so take them with a grain of salt   The least flawed by far is Peter Lawrey s  it does warmup runs to get the methods jitted  and it  consciously  defeats escape analysis to ensure the allocations are actually occurring   Even that one has its problems  though  for example  the tremendous number of array stores can be expected to defeat caches and store buffers  so this will wind up being mostly a memory benchmark if your allocations are very fast    Kudos to Peter on getting the conclusion right though  that the difference is  150ns  rather than  2 5x    I suspect he does this kind of thing for a living

User · Answer

You may find that A a   new A   is being optimised out by the JVM  If you put the objects into an array  they don t perform so well     The following prints     new A    141 ns A class newInstance    266 ns new A    103 ns A class newInstance    261 ns  public class Run       private static final int RUNS   3000000       public static class A              public static void main String   args  throws Exception           doRegular            doReflection            doRegular            doReflection               public static void doRegular   throws Exception           A   as   new A RUNS           long start   System nanoTime            for  int i   0  i  lt  RUNS  i                  as i    new A                      System out printf  new A      d ns n    System nanoTime   - start  RUNS              public static void doReflection   throws Exception           A   as   new A RUNS           long start   System nanoTime            for  int i   0  i  lt  RUNS  i                  as i    A class newInstance                      System out printf  A class newInstance      d ns n    System nanoTime   - start  RUNS             This suggest the difference is about 150 ns on my machine

User · Answer

There is some overhead with reflection  but it s a lot smaller on modern VMs than it used to be   If you re using reflection to create every simple object in your program then something is wrong  Using it occasionally  when you have good reason  shouldn t be a problem at all

User · Answer

Yes - absolutely  Looking up a class via reflection is  by magnitude  more expensive   Quoting Java s documentation on reflection      Because reflection involves types that are dynamically resolved  certain Java virtual machine optimizations can not be performed  Consequently  reflective operations have slower performance than their non-reflective counterparts  and should be avoided in sections of code which are called frequently in performance-sensitive applications     Here s a simple test I hacked up in 5 minutes on my machine  running Sun JRE 6u10   public class Main        public static void main String   args  throws Exception               doRegular            doReflection               public static void doRegular   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a   new A                a doSomeThing                      System out println System currentTimeMillis   - start              public static void doReflection   throws Exception               long start   System currentTimeMillis            for  int i 0  i lt 1000000  i                          A a    A  Class forName  misc A   newInstance                a doSomeThing                      System out println System currentTimeMillis   - start             With these results   35    no reflection 465    using reflection   Bear in mind the lookup and the instantiation are done together  and in some cases the lookup can be refactored away  but this is just a basic example   Even if you just instantiate  you still get a performance hit   30    no reflection 47    reflection using one lookup  only instantiating   Again  YMMV

User · Answer

In the doReflection   is the overhead because of Class forName  misc A    that would require a class lookup  potentially scanning the class path on the filsystem   rather than the newInstance   called on the class  I am wondering what the stats would look like if the Class forName  misc A   is done only once outside the for-loop  it doesn t really have to be done for every invocation of the loop

User · Answer

Significant  is entirely dependent on context   If you re using reflection to create a single handler object based on some configuration file  and then spending the rest of your time running database queries  then it s insignificant  If you re creating large numbers of objects via reflection in a tight loop  then yes  it s significant   In general  design flexibility  where needed   should drive your use of reflection  not performance  However  to determine whether performance is an issue  you need to profile rather than get arbitrary responses from a discussion forum

User · Answer

Reflection is slow  though object allocation is not as hopeless as other aspects of reflection   Achieving equivalent performance with reflection-based instantiation requires you to write your code so the jit can tell which class is being instantiated   If the identity of the class can t be determined  then the allocation code can t be inlined   Worse  escape analysis fails  and the object can t be stack-allocated   If you re lucky  the JVM s run-time profiling may come to the rescue if this code gets hot  and may determine dynamically which class predominates and may optimize for that one   Be aware the microbenchmarks in this thread are deeply flawed  so take them with a grain of salt   The least flawed by far is Peter Lawrey s  it does warmup runs to get the methods jitted  and it  consciously  defeats escape analysis to ensure the allocations are actually occurring   Even that one has its problems  though  for example  the tremendous number of array stores can be expected to defeat caches and store buffers  so this will wind up being mostly a memory benchmark if your allocations are very fast    Kudos to Peter on getting the conclusion right though  that the difference is  150ns  rather than  2 5x    I suspect he does this kind of thing for a living

User · Answer

I think it depends on how light heavy the target method is  if the target method is very light e g  getter setter   It could be 1   3 times slower  if the target method takes about 1 millisecond or above   then the performance will be very close  here is the test I did with Java 8 and reflectasm    public class ReflectionTest extends TestCase            Test     public void test perf             Profiler run 3  100000  3   m 01 by refelct      - gt  Reflection on X class   new   invoke  m 01    printResult                Profiler run 3  100000  3   m 01 direct call      - gt  new X   m 01    printResult                Profiler run 3  100000  3   m 02 by refelct      - gt  Reflection on X class   new   invoke  m 02    printResult                Profiler run 3  100000  3   m 02 direct call      - gt  new X   m 02    printResult                Profiler run 3  100000  3   m 11 by refelct      - gt  Reflection on X class   new   invoke  m 11    printResult                Profiler run 3  100000  3   m 11 direct call      - gt  X m 11    printResult                Profiler run 3  100000  3   m 12 by refelct      - gt  Reflection on X class   new   invoke  m 12    printResult                Profiler run 3  100000  3   m 12 direct call      - gt  X m 12    printResult               public static class X           public long m 01                 return m 11                          public long m 02                 return m 12                          public static long m 11                 long sum   IntStream range 0  10  sum                assertEquals 45  sum               return sum                        public static long m 12                 long sum   IntStream range 0  10000  sum                assertEquals 49995000  sum               return sum                      The complete test code is available at GitHub ReflectionTest java

User · Answer

There is some overhead with reflection  but it s a lot smaller on modern VMs than it used to be   If you re using reflection to create every simple object in your program then something is wrong  Using it occasionally  when you have good reason  shouldn t be a problem at all

User · Answer

Often you can use Apache commons BeanUtils or PropertyUtils which introspection  basically they cache the meta data about the classes so they don t always need to use reflection

[java] Java Reflection Performance

Examples related to java

Examples related to performance

Examples related to optimization

Examples related to reflection