Reflection better than bytecode generation ?

dia100 · **Joined:** Mon Sep 08, 2003 4:30 pm **Posts:** 203

Hi all,
From the Hibernate website:

Quote:

Hibernate rejects the use of build-time code generation / bytecode processing. Instead, reflection and runtime bytecode generation are used and SQL generation occurs at system startup time. This decision ensures that Hibernate does not impact upon IDE debugging and incremental compile.

As performance is crucial in an ORM tool I was wondering why should I prefer

Code:

reflection and runtime bytecode generation

versus build-time code generation ?

Check here:
http://www-106.ibm.com/developerworks/j ... j-dyn0603/

Somewhere in the article it says:

Quote:

execution time using reflection is over 1000 times greater than that using direct access

It looks like reflection has a _severe_ impact on performance. My question is: is Hibernate _core_ functionality based on reflection?

thx in advance,
--steve p.

christian · **Posted:** Thu Feb 19, 2004 5:59 pm

Hibernate uses a well thought-out mix of reflection and runtime bytecode generation for proxies. Don't worry, the overhead is minimal in any case and not visible if a remote database is used.

http://www.hibernate.org/Documentation/PerformanceQA

michael · **Posted:** Thu Feb 19, 2004 6:00 pm

Hibernate uses runtime in-memory bytecode generation using cglib to avoid reflection overhead. Compile-time bytecode generation sucks. http://www.hibernate.org/15.html#A3

dia100 · **Joined:** Mon Sep 08, 2003 4:30 pm **Posts:** 203

thx for the answers.

Though, from the website:

Quote:

In the very latest versions of Hibernate, "reflection" is optimised via the CGLIB runtime bytecode generation library. This means that "reflected" property get / set calls no longer carry the overhead of the Java reflection API and are actually just normal method calls. This results in a (very) small performance gain.

So the performance gain is very small when using reflection+CGLIB instead of reflection only?

TIA.

michael · **Posted:** Thu Feb 19, 2004 6:10 pm

cglib replaces reflection with runtime generated bytecode which looks exactly like the bytecode of a normal method call (without reflection)

stolley · **Posted:** Fri Feb 20, 2004 1:41 am

Steve,

Reflection is made up of two fundamental aspects - introspection and invocation. (google them)

Any discussion of the performance of reflection that does not explicitly address these two aspects is so flawed as to be useless.

Introspection is slow - it has to be, by it's nature.
Invocation on the other hand, is actually not too shabby in Java.

I looked at the guy's code and he measures the introspection time as well as the invocation time for his test.

If you actually care about this, rewrite his test to measure introspection time separately from invocation time.

Then we can have an informed discussion, where-in we can discuss things such as:
- how much introspection Hibernate performs versus how much invocation
- the degree to which the actaul overhead of reflective invocation even matters in the face of the real amount of time it takes to actually make a database call

I, for one, would be interested in reading that discussion.

But not unless all the participants have cashed in their clue-pons.

gavin · **Posted:** Fri Feb 20, 2004 2:13 am

And the answer is that Hibernate never performs introspection at runtime. And, incidentally, it never has, right from the very earliest versions. In modern JVMs a reflective invocation is barely slower than a normal method invocation.

Anyway, Hibernate core now only uses reflection as a fallback when CGLIB can't be used (eg. for a private method).

This is a nonexistent issue.

dia100 · **Joined:** Mon Sep 08, 2003 4:30 pm **Posts:** 203

Thx to everybody. Now it's clear for me. Long live Hibernate !