Performance and scalability: Performance issues using Reflection API
Are there any issues or performance hits while using reflection on the server side?
- Posted by: Jyot Singh
- Posted on: October 22 2002 11:44 EDT
I have to load all the appropriate event handlers based on the event object.
Which of the option is better :
1- Load the preinstantiated classes using properties file containing eventname and handler class name mapping.
2- Use the reflection to load the handler classes.
Thanks in advance
- Performance issues using Reflection API by Ravi Shankar on October 23 2002 08:23 EDT
Both your options require reflection, since in 1, the class name will be read from file as a string. The difference between the two options is that in 1, you instantiate all the handlers on startup, while 2 does lazy instantiation of the handlers (and caches them, I hope).
Reflection is slower than direct instantiation, no doubt. In my experience, it is slower by at least an order of magnitude. But there is no way around it if you don't want to hard-code the mapping between event and handler.
Which option is better?
Option 1: will take longer for the server to start up, but will give uniformly fast performance right after start up.
Option 2: server will start up quicker, but it will take a while to reach the same performance level. It will eventually, after all the classes get loaded and cached.
Hybrid option: pre-load the frequently used ones and load the rest on demand. i.e., a mix of options 1 and 2. this is useful if not all the handlers are equally likely to be used.
Lastly, all of these considerations are significant only if
- your classes are very big
- there are many of them
- they do time-consuming stuff during instantiation
If memory is not a concern, then go for option 1.
Are there any other options to explore for the same - with high performance and preferred decoupling ?
Jyot, The performance overhead of reflection is insignificant in initialization. The benefits that reflection brings--loose coupling, with the ability to switch implementations of any interface in configuration files, without modifying Java code--far outweigh the cost. So I would definitely use reflection in your case.
Also, the performance overhead of reflection is often exaggerated. In modern JVMs (1.3 and 1.4) it is getting less and less. Typically, the work that a method does will far outweigh whether it's invoked reflectively. Remember that JSP, EJB and other J2EE technologies are based on reflection.
I look in detail at how to use reflection to configure applications in my new book, Expert One-On-One J2EE Design and Development, which you might find interesting. The book comes with generic code to implement this approach.
Thanks a lot for your valuable input.I 'll definitly browse the book.Apparentlly,I had this concern when I saw the actual performance difference (more than 60%) between normal method call to reflection call on a profiler tool.This prompted me to explore different options for the same.Recently,I read 1.4 docs and I totally agree with you on the considerable improvement using reflection.