14

I have question, maybe from someone it see as stupid. Is Hibernate fast? I use it in system which would have really large count of queries to database. And performance become alerted. And other question off the point of current context. What would better - many simple query (with single table) or a bit less query with several JOIN?

Tanks for advance Artem

matt b
  • 138,234
  • 66
  • 282
  • 345
Tioma
  • 2,120
  • 9
  • 35
  • 52
  • possible duplicate of [Can Hibernate be used in performance sensitive applications?](http://stackoverflow.com/questions/651664/can-hibernate-be-used-in-performance-sensitive-applications) – splash Mar 01 '11 at 14:26
  • We have released Batoo JPA that is ~15 times faster then Hibernate and implements the JPA Spec %100. The main motivation of the project was all three JPA implementations are simply put slow. Having realized JPA could be much faster, we have developed Batoo JPA. Give it a try http://batoo.jp – Hasan Ceylan Oct 06 '12 at 07:00

8 Answers8

16

From our experience Hibernate can be very fast. However, there can be many pitfalls that are specific to ORM tools including:

  • Incorrect lazy loading, where too much or too little data is selected
  • N+1 select problems, where iterating over collections is slow
  • Collections of List should be avoided and prefer Set so ordering information does not need to be included in the table
  • Batch actions where it's best to fall back to direct SQL

The Improving Performance page in the Hibernate docs is a good place to start to learn about these issues and other methods to improve performance.

Uriah Carpenter
  • 6,656
  • 32
  • 28
14

First of all, there are many things you can do to speed up Hibernate. Check out these High-Performance Hibernate Tips article for a comprehensive list of things you can do to speed up your data access layer.

With "many" queries, you are meeting with the typical N+1 query problem. You load an Entity with Hibernate, which has related objects. With LAZY joins, you'll get a single query for every record. Each query goes through the network to your database server, and it returns the data. This all takes time (opening connection, network latency, lookup, data throughput, etc.).

For a single query (with joins) the lookup and data throughput are larger than with multiple queries. But you'll only have the opening of the connection and network latency just once. So with 100 or more queries you have a small lookup and data throughput, but you will have it 100 times (including opening the connection and network latency).

A single query that takes 20ms. vs 100 queries that take 1ms.? You do the math ;)

And if it can grow to be 1000's of records. The single query will have a small performance impact, but 1000's of queries vs 100's are 10 times more. So with multiple queries, you'll have reduced the performance greatly.

When using HQL queries to retrieve the data, you can add FETCH to a JOIN in order to load the data with the same query (using JOIN's).

For more info related to this topic, check out this Hibernate Performance Tuning Tutorial.

Vlad Mihalcea
  • 142,745
  • 71
  • 566
  • 911
SPee
  • 656
  • 4
  • 5
3

Hibernate can be fast. Designing a good schema, tuning your queries, and getting good performance is kind of an artform. Remember, under the covers its all sql anyway, so anything you can do with sql you can do with hibernate.

Typically on advanced application the hibernate mapping/schema is only the initial step of writing your persistence layer. That step gives you a lot of functionality. But the next step is to write custom queries using hql that allow you to fetch only the data you need.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
3

Yes, it can be fast. In past i got several cases when people think "aaaa it's this stupid ORM kills all performance of our nice application" in ALL cases after profiling we found out other reasons for problem. (bad hash code implementation for collections, regExps from hell, db design made by mad hatter & etc.)

Actually it can do the job in most of the common cases. If you migrate huge and complex data - it will be poor competitor to plain well optimized SQL (but i hope it's not you case- i personally hate data migration with passion :)

Dmytro
  • 195
  • 5
2

Hibernate could be reasonable fast, if you know how to use it that way. However, polepos.org performance tests shows that for Hibernate could slow down applications by orders of magnitude.

If you want ORM which is light and faster, I can recommend fjorm

Mladen Adamovic
  • 3,071
  • 2
  • 29
  • 44
2

This is not the first question about it, but I couldn't find an appropriate answer in my previous ones (perhaps it was for another "forum"). So, I'll answer once again :-)

I like to answer this in a somewhat provocative way (nothing personal!): do you think you'll be able to come with a solution which is better than Hibernate? That involves not only the basic problems, like mapping database columns to Java properties and "eager or lazy loading" (which is an actual concern from your question), but also caching (1L and 2L), connection pooling, bytecode enhancing, batching, ...

That said, Hibernate is a complex piece of software, which requires some learning to properly use and fine tune it. So, I'd say that it's better to spend your time in learning Hibernate than writing your own ORM.

jpkroehling
  • 13,881
  • 1
  • 37
  • 39
  • Thanks. You've convinced me to use Hibernate without fail:) Why I doubt. I expect that would more then 100 mil records for one table and from it 200 queries in one sec(approximate). And it only one table for input data. In requirements to project - 1 sec to response from server. And about each operation necessary log into database. That's why I really doubt regarding Hibernate. – Tioma Mar 01 '11 at 15:58
  • The Hibernate's ability to cope with SQL queries don't worry me. If the generated SQL is not satisfactory, you can always use a "native" SQL query. The biggest concern would be creating the SessionFactory. If you are using an application server, or if you open a session only once for a thousand operations, you should be fine. – jpkroehling Mar 01 '11 at 16:45
0

... which would have really large count of queries to database ...

If you still in design/development phase do not optimize preventive.

Hibernate is a very well made piece of software and beware of performance issues. I would tell you when you project is more mature to go into performance issues and analyse for direct JDBC usage where necessary.

PeterMmm
  • 24,152
  • 13
  • 73
  • 111
0

It's usually fast enough, and can be faster than a custom JDBC-based solution. But as all tools, you have to use it correctly.

Fast doesn't mean anything. You have to define maximum response time, minimum throughput, etc., then measure if the solution meets the requirements, and tune the app to meet them if it doesn't.

Regarding joins vs. multiple queries, it all depends. Usually, joins are obviously faster, since they require only one inter-process/network roundtrip.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255