I am running a test with Hibernate and direct JDBC to read data from one table.

I am using DB2 and Hibernate (2.0.3 and 2.1b6). I am running the test in a loop and reading all the data in one table (1000 records). The persistent Object contains only 3 (String) attributes.

I used test class similar to net.sf.hibernate.test.PerformanceTest. JDBC is 2.2 to 3.5 faster than Hibernate (No substantial difference between 2.0.3 and 2.1, and caching and no caching). Am I missing something?

Below are the 2 methods I tested:

private static void testHibernate(Session s) throws Exception {
List list = s.createCriteria(test.Test.class).list();
s.connection().commit();
}

private static void testJDBC(Connection c) throws SQLException {
PreparedStatement select = c.prepareStatement("SELECT * FROM Test");
java.sql.ResultSet rs = select.executeQuery();
List list = new ArrayList();
while ( rs.next() ) {
Test test= new Test();
test.setAtt1(rs.getString(1));
test.setAtt2(rs.getString(2));
test.setAtt3(rs.getString(3));
list.add(test);
}
rs.close();
c.commit();
}

Thank you,

mota

This is not completely unexpected. You test is about as far from a realistic test as you can possibly get. When you run queries like this the database responds unrealistically quickly because

* the database completely caches the entire table in memory
* you are running against a local db, so no network traffic
* the database is not under load
* there are no concurrent reading threads
* especially, there are no concurrent writing threads

In a production system it is very common that NONE of these conditions hold. In production, the overhead of Hibernate is certainly unmeasurable.

Nevertheless, I NEVER measure differences anywhere approaching 100%-200% on DB2 (I do see this for some tests against in-memory HSQLDB, which is not a real database).

So, probably you are doing something wrong. Performance profiling with a database is EXTREMELY tricky and can give some bizarre incorrect results in toy test cases like this.

However, you should be aware that:

* the Criteria API is slower than HQL, because compiled queries cannot be cached

Try the same query in HQL, where the SQL does not need to be rebuilt each time. That may possibly account for the difference.


P.S. Also try throwing an insert or update into your loop, and see if the performance difference disappears. (If it doesn't, you are definitely doing something wrong.)

PS2. Now try enabling the query cache in 2.1, and watch Hibernate outperform direct jdbc by probably a greater margin ;)

Oh, and one final thing. You are not executing the same SQL, so it is not "fair". Dunno if that makes a difference.

I am using DB2 on a remote server. I used the same sql generated by Hibernate in JDBC and replaced the setString(order) by setString("Field"). The performance improved: JDBC is now 2.3 times faster.

I think Hibernate caching does not have any impact in this scenario, as a value is read only once in a session. Are there any other ways to improve reading performance? Please give more details on how to implement them.


Thank you,

mota

If DB2 is remote, and JDBC is 2 time faster, your test is broken ;)

Guaranteed. You are doing something fundamentally wrong. (And no, I'm not going to even try to fix your test for you ... its impossible w/o being there.)





No, the new query cache would help. (Its undocumented so far, but it works.)

I ran some similar tests and Ive reached the same conclusion as Mr. Mota. The performance issues aside, Hibernate does not speed up my development at all. Maintainability? If I'm looking at 10 years down the road, I really dont see any guarantee that I wont have to rework my app to pull the guts out of hibernate and replace my object mapping with some other object oriented holygrail if and when Hibernate dies out due to core developers leaving, new database technology introduced that address performance, etc.

On the same token, I'm having a hard time trying to convince others on my team why it is advantageous to write in hibernate query language rather than sql. Really, all I'm doing here is moving some code into xml documents.

Is Hibernate really worth the RTFM to hack it into the guts of some applications?

Well, you can use Cobol if you like stability for the next 20 years. If you can't sell an abstraction layer to SQL, your team propably hasn't had enough problems with SQL in the past, which is strange.

There is no guarantee that ORM will solve your problems and speed up your development, it depends on your specific projects.

What I'm debating is whether to keep/write our own ORM layer or use Hibernate and write xml instead of our own java/xml code. Hibernate's caching scheme is great and all, provided if you evict them properly, but we still had to come up with our own random access file scheme for heavy duty caching.

Are you seriously asking if it is easier to write a full object/relational mapping middleware yourself or use a proven and mature existing one?

We are talking about 2 man years developer time here and 50.000 lines of complex code. I don't even want to know what a "random access file caching strategy" is. :)

All what I am looking for is how to use Hibernate in the best possible way.
I changed the line:
List list = s.createCriteria(test.Test.class).list();
to:
List list = s.find("from test.Test");

I also used different connection pools: Hibernate, C3P0, DBCP.

These actions did not produce noticeable differences.

However, when I commented out the element "<jcs-cache usage="read-only" />" in the mapping file the performance improved little bit: JDBC is now only 1.7-1.8 times faster than Hibernate.

I have some read-only data in my application, and I am trying to develop a demo to show how Hibernate is fast in getting read-only data. Are there any guidelines to follow for read-only data?

Thank you,

mota

Have you read the first reply by Gavin where he explains what is wrong with your test?

Christian,

I dont think Gavin answered Mr. Mota's question at all except that he needs to test something else instead of what he's looking for. Perhaps, you could give us some expert inputs, sir.

I can't read it for you on the phone, sorry.

Thank you for the one-liner, sir.