How much overhead do frameworks like Hibernate bring?

Developers are sometimes scathing of mult-tier Enterprise web applications... 'Enterprise' is viewed by some as synonymous with slow, bloated and resource-hungry.

Do frameworks such as Hibernate actually bring in a non-trivial impact on performance compared to writing your own DAOs or other less abstracted approaches? By non-trivial I suppose the question is "does the user notice pages load slo开发者_如何学Cwer as a result".

With proper usage you are likely to improve performance rather than decrease it. In most cases you'll get comparable performance and when there're problems you'll have much more time to troubleshoot them.

PS Remember to use proper tools with Hibernate like Hibernate profiler. They can make wonders!

PPS Using Hibernate is not a replacement for knowing your SQL!

That really depends on what you are doing or more exactly how you use the framework. Also, with today's hardware capabilities what is an issue today might not count in a few months.

Not sure if you ask this because there is an application requirement which says that performance is important or you are just wondering, but consider this: there were some people that used Hibernate in an application and noticed it was sloooow. Then some guys refactored it, optimized it, with plain JDBC, iBatis or whatever and it ran faaaaast. So, the conclusion was: Hibernate is slow.

But they did not consider that the technology was misused. Yeah... it's cool that you can write object.getX().getZ().getW().getSomeOtherThing().getEtc() and it just works, but Hibernate will generate the SQL and Heaven help you there.

Before doing anything, consider the rules of optimisation:

• First rule of optimization - Don't do it.
• Second rule of optimization (for experts) - Don't do it... yet.

Adding a framework is usually a good thing because it eases development. If it adds overhead? Well... you can't tell just by looking at it. You have to profile it and test it.

By non-trivial I suppose the question is "does the user notice pages load slower as a result".

For most CRUD applications, it's the contrary actually. Properly used and tuned, Hibernate will generate better SQL than most developers (sorry to say that but it's true) and features like lazy-loading, first level caching (transaction-level cache), second level caching (global-level cache), query caching will make it perform better than lower level approaches (custom SQL and DAOs).

And because someone mentioned batch updates and large result sets, I'd underline that Hibernate has a StatelessSession for these use cases. But I don't think that they're in the scope of the interactive part of a webapp (if your search retrieves 10⁶ records in a webapp, you are doing it wrong).

It depends a lot on what you're doing. Generally your users won't notice a difference on the front-end but there are a few things to watch out for:

• ORM mappers aren't great at doing batch updates or handling large results sets.

• If you have a complex set of relationships your ORM mapper might slow things down because it does joins in the "wrong" way. Or fetches too much data.

• If your site has really heavy load the extra CPU cycles might get in the way but it is unlikely.

An ORM mapper can make your software much easier to develop. Keep an eye on performance and do the 1% of things in straight SQL but keep Hibernate in the other 99% of things.