Hi,
I use hibernate (+ annotations, entity manager) in a desktop application. The database access via hibernate is much slower (in all cases) with the 3.5.0 release compared to the 3.3.2 release. Are there known performance issues in the 3.5.0 release?

Database: MySQL 5.1

Best regards
QStorm

Seems I am alone with this issue. Isnt it?

I found one more person speaking about degraded performance in the Search forum:
https://forum.hibernate.org/viewtopic.php?p=2428818#p2428818

do you have a simple test or demo app that could highlight this issue?

QStorm, hibernate 3.5 is unusable for us the performance difference is so extreme. We had to revert back to the previous version we were using, 3.3.1. I don't know exactly where the issue lies. I would assume hibernate 3.5 has an enormous bug, but we're also managing it with Spring. Are you using Spring as well?

The situation with us is we have Person entities referring to common Event entities. So person A and person B might refer to Event 1. We have to save thousands of people, we do this in batches of 20 for performance. So if person A is saved, Event 1 is saved also by cascading the save. But person B is not yet saved. Then when person B is saved, Event 1 no longer needs saving so we're all good.

In hibernate 3.3.1, saving thousands of people takes seconds. hibernate 3.5 might take weeks if we let it, gradually increasing the time it takes to commit. Commits should be very quick as the inserts are done immediately. However, if we remove all the relationships between people and events, hibernate 3.5 is quick again... maybe not as quick as 3.3.1, but usable.

Everything else seems to work fine with hibernate 3.5, all our unit and functional tests pass.. the problems arise when saving many entities with shared relationships.

We will try and write a minimal test case to post to JIRA as soon as possible.

AFAIK dirty checking has always been a performance problem, is it possible the number of managed objects in your session is growing?
Are the first batches roughly as fast as before?
Might make sense to try comparing 3.3.2 with 3.5 when closing the session at the end of each bath.

The first batches are slower in 3.5, but not a tremendous amount slower. A session can survive beyond a transaction? We use spring to manage our transactions and end the transaction after each batch is saved. I'll try closing the session before the batch save method ends.. After the method ends would require adding a ton of ugly code

does v3.3.1 auto close sessions when a transaction ends whereas 3.5 does not?

no version ever closed the sessions at transaction end, as far as Hibernate concerns. No clue what Spring could be doing.

While the most common approch is having a match 1:1 session:transaction, like

• openSession
• beginTX
• ...operation
• ...operation
• commitTX
• closeSession

it's sometimes usefull to have

• openSession
• beginTX
• ...operation
• commitTX
• beginTX
• ...operation
• commitTX
• closeSession

Hi,
Any news on this issue? Are there any performance improvements in the new 3.5.1 releases, or should I go back to the 3.3.1 version?

Thanks an best regards
QStorm

Emmanuel is waiting for a testcase from mueller, but his case appears to be affected by a regression limited to Hibernate Search.
Could you provide us with a testcase to reproduce the problem? It's faster for my use cases.

I don't know if it the case for the rest of you, but I've found that while "show_sql" is true performance can get very low.
I had query run for about 3 minutes with show_sql=true and after turn it off it return in under 2 seconds.
I may have chose bad impl for slf4j, I don't know, but now hibernate 3.5.0-final performs great.

Ido.

You are not alone, I haven't been able to narrow it down but was finding what seemed to be a 25% hit with 3.5.0 with 3.3.2. This is on identical code (aside from cleaning up some of the api changes) running the same test suite. Using annotations + the native criteria API.

However, it's all hit and miss as well since our IT policy is now scanning every file that is touched which is wreaking havoc on the performance profile in general.

I'm also hit by the somewhat nasty many to many bug so that's preventing me from upgrading in the first place.

After some testing to the wee hours last night, I'm really no further ahead. If I run my test suite wide open I can see that overall it's taking 25% more time. However, if I take the slower tests and run them by themselves then I get almost identical timings between the 2 releases so, for me, I'm finding it very obscure and might be a mem issue where something might be holding onto some references that it didn't before. I gave my tests some extra heap last night and it didn't seem to make a diff.