Good answer above.
Hibernate is "complex" and so unpicking its performance strengths and weaknesses is really hard, and I would agree with the above - you need to write real code and
test its performance.
But as mentioned in a separate post, if you try to use hibernate for a job it's not good at (eg bulk operations or complex reporting), then you are certain to see horrible performance problems. Its common to see projects writing code that accidentally generates 100x the number of SQL statements needed, because they've misunderstood the purpose of Hibernate (as an object/relational mapper) and they've forgotten that you can use hibernate AND regular SQL in the same project.
Use correctly, Hibernate can outperform hand written SQL because:
1) as mentioned above, caching can help a lot - in a single transaction hibernate won't repeat the same select statement if you inadvertently keep re-requesting the same object
2) automatic dirty checking can be quite efficient at optimizing the update statements needed, sometimes when writing JDBC by hand you might find yourself issuing unnecessary UPDATE statements because you're not sure if an object's state has changed - hibernate can do this automatically.