There is a benchmark result about ORM tools http://www.middlewareresearch.com/torpe ... sp#compare.
Are those biased tests? Thanks! Stan

we have already talked about this bench .
I don't how someone can said that the power of an orm is based on the number of database hits... no matter we are not bad at this.

The last time I had a (very brief) look at this benchmark and the results, it was clear to me (knowing Hibernate's feature set) that we can get to the same number of queries, if needed (actually, we can get much lower with a disk-backed second-level cache). There just hasn't been time to come up with some better implementation and frankly, I don't see it anywhere on the TODO.

I've also the opinion that all "full" ORM solutions will eventually (with correct implementations) have the same low number of queries. This benchmark is not really useful in answering performance questions, only a real load benchmark can do that. However, this is much more difficult to create.

Sorry for reposting. I did search on this forum for the threads about this bench before posting and did not find any. Could you please point me to that thread so that I can get more information?

One more question. Is TPC-C bench (http://www.tpc.org/) suitable to evaluate ORM tools (using the same HW, AS and DBMS)?

Thanks! Stan

to make real bench, you have to:
- test your app at the extreme level (a lot of users) --> heavy test
- test your app with "realistic" load but during a long time --> endurance test

with this you'll see:
- memory & cpu on both app server AND database
- network traffic
- exception handling
- response time

I use loadrunner in my company, it allows to do all this but is very expensive.

One thing torpedo is showing is that there is a big difference between tuned and untuned, i think the real point is to make good use of a tool.
And trust me, if you are expert in hibernate you'll be able to have a very performant app (not really the same with ejb entity). Unfortunatly it only deals with database hit.
Just remind that one _too complex_ sql query can sometimes kill your database and that, for the same result, 3 or 4 queries can be more performant....