ORM solutions (JPA; Hibernate) vs. JDBC

Question

I need to be able to insert/update objects at a consistent rate of at least 8000 objects every 5 seconds in an in-memory HSQL database.

I have done some comparison performance testing between Spring/Hibernate/JPA and pure JDBC. I have found a significant difference in performance using HSQL.. With Spring/Hib/JPA, I can insert 3000-4000 of my 1.5 KB objects (with a One-Many and a Many-Many relationship) in 5 seconds, while with direct JDBC calls I can insert 10,000-12,000 of those same objects.

I cannot figure out why there is such a huge discrepancy. I have tweaked the Spring/Hib/JPA settings a lot trying to get close in performance without luck. I want to use Spring/Hib/JPA for future purposes, expandability, and because the foreign key relationships (one-many and many-many) are difficult to maintain by hand; but the performance requirements seem to point towards using pure JDBC.

Any ideas of why there would be such a huge discrepancy?

Answer 1

Hibernate maintains a first-level cache of objects to use in dirty checking as well as to act as a Unit of Work and Identity Map. This adds to the overhead, especially in bulk-type operations. For bulk operatons, you may want to investigate StatelessSessions that don't maintain this state.

Answer 2

We have similar experience comparing Hibernate with JDBC in batch mode (Statement#executeBatch()). Basically, it seems like Hibernate just doesn't do that well with bulk operations. In our case, the Hibernate implementation was fast enough on our production hardware.

What you may want to do, is to wrap your database calls in a DAO, giving your application a consistent way of accessing your data. Implement your DAOs with Hibernate where it's convenient, and with JDBC where the performance requirements call for it.

Answer 3

All that mapping ... it can get a little bit expensive, with all the arcane logic and all the reflection and consistency-checking that it has to do.

The point of mapping is not to boost performance, of course. Typically, you take a performance hit. But what you lose in performance, you (can) gain many times over in developer productivity, consistency, testability, reliability, and so many more coveted attributes. Typically, when you need the extra performance and you don't want to give up mapping, you drop in some more hardware.

Answer 4

As a minimum, you need to do batch inserts in Hibernate: http://www.hibernate.org/hib_docs/reference/en/html/batch.html Saves a lot of round-trip time.

And, as Justice mentioned, the primary goal of Hib is not computer performance, but developer performance. Having said that, it's usually possible to achieve comparable (not equal, but not that much worse) to JDBC results.

Answer 5

Never use one technology for all problems. Depending on the problem decide what technology to use. Of course jpa or hibernate is slower than jdbc. jdbc is on lower level than jpa. Also a db professional with jdbc can write more optimized sql than jpa. If you gave critical point where speed is required, jpa is not your choise.