Well, somebody could also, say, that some guy _CAN_ make Java faster
than Java (if ASM done very bad), or JPA _CAN_ be done faster than JDBC
(if using JPA caches, while always scanning the table again using JDBC).
So if this is about 'CAN' then neither of JPA or JDBC is better.
In a real world scenario, the answer should be: When dealing with a lots
of rows in the same type of action (like mass inserts), JDBC is far
better than JDBC. If doing complex business tasks with lots of JOINS and
99% READ, then JPA will most of the time be faster than JDBC (thanks to
the caching which prevents repeated SQL parsing and table scanning). So
it depends more on the use case and less on the technology.
Also JPA is not build around JDBC. It is bould around O/R mappers. There
might be mappers that do not use JDBC at all. It is like ADO compared to
ODBC. Some vendors provide ADO wrappers around their ODBC drivers,
others provide compeltely separated code stacks. So for JPA and JDBC it
is the same (while I agree that most current JPA vendors currently are
using JDBC at the moment).
I know what you mean, but still I think it holds true that technology
chosen by use case is better than technology chosen by benchmark (i. e.
do not compare JPA and JDBC but check your actual use case first).
Regards
Markus
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: Donnerstag, 10. Juli 2008 10:53
To: users_at_glassfish.dev.java.net
Subject: Re: Re: JPA: speed vs JDBC
If you read my answer, you will see that what I was saying is basically:
1. Technically, JDBC _can_ always be _made_ faster than JPA
2. This does not imply that you should pick JDBC... writing in
assembly _can_ always be _made_ faster than writing in Java.
The key points are _can_ and _made_
99% of the time, it will be the other way around. i.e. Java code will
out perform assembly code and JPA will out perform JDBC code.
A ____very____ skilled assembly coder could (given a ___lot___ of
time) produce assembly code that is faster than Java. Of course such
code will be a lot harder to maintain, and the next round of
processors released by Intel & AMD will probably render the
optimizations redundant and the Java code will be as good as or better
than that hand crafted assembly code.
But if somebody asks which is the faster to run, the technically
correct answer has to be assembly, as that is the building block upon
which Java stands... you will always have some overhead because you
are standing on top of that assembly block. However, nobody programs
in assembly because its too low level, the overhead of Java is what
lets you be productive and produce a product.
With JPA vs JDBC, this is exactly the same. JDBC is the building block
upon which JPA is built. JPA (as a result of standing on the
shoulders of JDBC) can never be faster than _properly tuned_ raw JDBC.
However, the JDBC code that most developers will write is going to be
slower than JPA 99% of the time... and JDBC is usually too low a level
for most people anyway and they'll end up building an object mapping
framework on top of JDBC... which smells suspiciously like JPA... only
they wrote it themselves and therefore have not learned the mistakes
the JPA developers learned while developing JPA... and they cannot
just swap out to a different JPA provider becuase their custom
solution is not standards based.
And what is
On Thu, Jul 10, 2008 at 7:34 AM, Markus Karg <karg_at_quipsy.de> wrote:
> Despite the fact that I completely disagree to all of your arguments,
> this is the "apples-vs.-bananas" discussion I wanted to prevent.
>
> It is just neither true that Java is slow always, nor that always JDBC
Read my answer... where do I say Java is slower... if anything i say
99% of the time it is faster... but assembly has the potential to be
faster (if you have a really skilled developer)
> is faster than JPA. The real and complete answer is so complex that a
> persistence beginner like him (and I assume him to be a persistence
> beginner because otherwise he wouldn't try to replace JDBC by JPA or
So you would never replace one JPA query with a targetted JDBC query
because you found that 10 fold performance increase by hand tuning the
SQL query and throwing out the caching layer because you need the
answer straight from the DB?
What I was saying is that there is no need to write the whole app
using JDBC. _If_ you have developed an application with JPA _and_ you
find a performance bottlekneck at one query _then_ the good design
that JPA will have forced on your code will make it easier to replace
that one query with a direct JDBC call.
> vice versa) will not understand the real problems he runs in -- either
> with JDBC or JPA. First one must understand that both target in
totally
> different directions, so there is no choice whether to do X or Y in
the
> same project: The project will dictate the technology anyways.
>
> Regards
> Markus
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
> Sent: Mittwoch, 9. Juli 2008 23:28
> To: users_at_glassfish.dev.java.net
> Subject: Re: JPA: speed vs JDBC
>
> There is a simple answer to your question...
>
> JDBC can be optimized to be faster than JPA every time.
>
> I can be certain of this because, ultimately, under the hood, all the
> JPA providers are using JDBC...
>
> The real question you have to ask is do you have the time to develop
> and maintain your own object mapping layer and to do the optimizations
> that are specific to your problem domain that will make your JDBC
> based object mapping layer faster than one developed on the back of
> JPA.
>
> In my opinion, it is better to get something up and working first
> before trying to optimize.
>
> JPA uses POJOs, so if you need to do an optimization at a later point
> that is above and beyond what you can do by tuning JPA (or by changing
> the JPA provider) you should have not tied your code too much to JPA
> as to prevent switching the hot spots to JDBC...
>
> If you really care that much about performance you should not be
> writing your app in Java anyway... write it in assembly to get every
> processor cycle working for you... (oh but most JIT JVMs can optimize
> your Java into faster native code than 99% of C++/C/assembly
> developers could write, and developing in Java is quicker, so your
> competitors will have got to market first)
>
> -Stephen
>
> On Wed, Jul 9, 2008 at 7:25 PM, Markus KARG <markus.karg_at_gmx.net>
wrote:
>> This is like comparing apples and bananas. The performance is
> completely
>> dependent on what you want to achieve and what actual providers you
> are
>> using. You should decide for a technology on a design or architecture
> level.
>> If you really want to decide on a performance level, you have not
> understood
>> what both are good for. Both are neither competitive, nor comparable.
>> Besides that: Yes, I have performance benchmark results. But I will
> not post
>> them as they solely are taylored around my very own use cases, so
they
> are
>> no good for you at all.
>>
>> You should post what you want to do, and then we can give you tips
> what
>> would be the better / faster / less-footprint technology for you.
>>
>> Regards
>> Markus
>>
>> glassfish_at_javadesktop.org schrieb:
>>>
>>> Has anyone done some experiments on this topic? Looking forward to
> know
>>> the results.
>>> [Message sent by forum member 'bobxu' (bobxu)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=285393
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>
>>
>> --
>> http://www.xing.com/go/invita/58469
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net