JDBCPersistence Performance Measurements

It's been always considered that an ORM framework can never match performance of hand-written JDBC code. While being a fair statement, it relied, to a certain degree, on an assumption that implementation was based on reflection mechanism.
Majority of frameworks use java reflection mechanism, which, though improved in recent releases still does not match performance of bytecode. Also, as long as frameworks rely on interpretation of mapping information at runtime, there will always be CPU wasted on interpretation of configuration information.

Though, the overhead can be reduced greatly by minimizing amounts of interpretation via a variety of means e.g. caching, its share remains significant.

A different approach would employ compilation of mapping information into executable - bytecode, in essence implementing an ORM-language compiler, if there was such as language.

Furthermore, the compiler could create classes during application runtime when an instance of specific ORM mapping class was requried.

Every class generated by JDBCPersistence is an implementation of JDBCPersistor interface that maps a bean to table. JDBCPersistor interface establishes contract between static components of the framework and generated code. The interface defines methods to insert, update, delete, batch Insert, batch Update, batch Delete, and, findByPK and load data into java beans.

The generated bytecode, would be equivalent to one produced by java compiler from source similar in structure to the one below.

JDBCPersistor Implementation For ExampleUserBean
JDBCResultSetReader Implementation For ExampleUserBean

As the generated bytecode implements specific for an entity logic it needs not to use reflection, or interpret information at runtime, thus delivering performance matching that of JDBC code. The performance metrics were done on an HSQL in memory database. The comparison is done between JDBC handwritten code, JDBCPersistence, iBatis and Hibernate. Each operation was performed a few hundred times to arrive to smoother graphs.

Less, on the time axis, is faster.