Hibernate implementation. Are we paying the reflection penalty?

Question

Long time ago, I was creating a mini ORM using reflection.

While reading about reflection I got a similar answer like this:

Java Reflection Performance

Which makes completely sense and I quit my mini orm and sharpen my CTRL+C, CTRL+V keys ( the lib was intended to avoid having to rewrite again and again the same snippets for different tables in a web app I was working on )

Years later for some reason I don't remember now ( nor want to remeber ) I was reading ( or trying to... ) the Hibernate source code, for I wanted to know if they use AOP to generate code on the fly and avoid the reflection penalty, but for my surprise, all of what I saw was pure reflection.

Does it mean the most accepted ORM framework out there, did exactly what years before discourage me from continuing my naive efforts ?? :")

My question is: Can someone confirm my understanding of the Hibernate implementation? Do they generate bytecode on the fly to improve performance? Or are we ( when we use it ) always paying the reflection penalty ( which by the way, if the diff is in some ms, none of us have noticed nor complained about )

Are we paying the reflection penalty? If we are, I think it is worth it!!!

Regards.

Answer 1

Hibernate instruments your models to be hibernate aware.

There are varying levels of cost for using Reflection. Constantly looking up a method for a particular class is particularly expensive. Executing a method via reflection using a cached copy is not that much slower. If one thinks of the tasks that the reflection api must complete to invoke the method it all makes sense which each part is slow and consumes cpu cycles.

Locating a method

• Visit each and every method of a particular class
• Test each methods visibility, method signature etc.
• Generate bytecode for found method.

One factors in the numbers of methods in a typical class and that some of these operations arent trivial it becomes obvious that this can be costly.

Invoking the method.

Each reflected method amounts to a bit of byte code that invokes the target method with a bit of boilerplate to match the reflection interface. Before it can do that it must perform some sanity checks so it can complain with nice messages rather than letting the runtime throw ClassCastException and similar exceptions.

• If an instance method check the instance passed in isnt null and is the right type.
• Check the arguments parameter includes the right amount and type of parameters.
• Execute the method within a try catch. In the catch throw ITE etc.

All these extras add some cost - not a lot but it does make things slower.

Runtime costs

In general caching methods and invoking that isnt cost but is a bit slower. The reflection api itself does attempt to cache methods and classes but finding the right method and so on is still a slow operation.

Answer 2

I think the important thing to remember is the relative cost in the overall application. Is reflection slower then normal object creation? Yes. Has reflection got better and faster? Yes. But really these points aren't very important when comparing the cost of reflection versus going over the wire and doing something with the database, which is what hibernate does - the cost becomes completely negligible and I'd say we are not paying the price.

Answer 3

The cost of persistence and retrieval is many times the cost of reflection. To access a record from a DB might take 1-10 ms and to construct an object with reflection might take 0.001 to 0.01 ms.

Answer 4

Doesn't NHibernate cache the class info gathered through reflection so you only pay the penalty the first time?

Answer 5

You really pay the reflection penalty by using NHibernate but its extensibility allow you to avoid 90% of them if you provide all optimized reflection implementation via NHibernate.Bytecode.IBytecodeProvider.