• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is JDBC really faster than ORM tools?

 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi folks,

All the books that I'm reading about 1z0-807 content states that ORM tools are essentially slower than JDBC tools. Do you agree with that? I disagree completely, we can't say that a one more layer should impact the performance as this. We can say that those kind of tools have an potential to be slower because developers just forget about the optimizations, but they can optimize a lot of things using ORM tools.

Do you agree with that folks? We can state that ORM is slower than JDBC?
 
Bartender
Posts: 1357
39
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think that there may be a single and definitive answer to your question. Generally speaking, I presume that using JDBC you can manage better some circumstances where ORM may result oversized - for example retrieving a bunch of sparse information from an ad hoc join table. But the real data crunching should be better performed at stored procedure level, where you can unleash all the power of your target database. It's a pity that there is no a portable way for writing stored procs, even if ORMs gained a lot of flexibility even in this ambit.
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I liken that to the old "Assembly Language is faster" argument. Software products used to brag about being written in assembler.

The general answer is that, like assembly language, raw JDBC is more performant at small scale. That's because you can take the time to precisely tune what's going on.

Once things get bigger and more complex, however, the more complex systems (compilers and ORMs) begin to take the lead. That's because they can track more things than can be economically tracked by a person and can track them in real time, adjusting the environment both globally and locally.

I've seen benchmarks that showed ORMs running at twice the throughput of raw JDBC, but Your Mileage May Vary. The primary benefits of ORMs aren't in performance, they're in design and maintenance costs. You don't need to be a thorough SQL expert to do complex joins using an ORM (though it doesn't hurt!). The performance benefits are a plus, but as always, "knowing" what's performant and what isn't is useless. If it matters, measure!
 
reply
    Bookmark Topic Watch Topic
  • New Topic