|
Replies:
13
-
Last Post:
Jul 12, 2008 5:15 AM
by: christiaan_se
|
|
|
|
|
|
|
JPA: speed vs JDBC
Posted:
Jul 9, 2008 7:50 AM
|
|
|
Has anyone done some experiments on this topic? Looking forward to know the results.
|
|
|
|
|
|
|
Re: JPA: speed vs JDBC
Posted:
Jul 9, 2008 11:25 AM
in response to: bobxu
|
|
|
|
|
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@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@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
--
http://www.xing.com/go/invita/58469
[smime.p7s]
|
|
|
|
|
|
|
|
|
Re: JPA: speed vs JDBC
Posted:
Jul 9, 2008 2:27 PM
in response to: Markus KARG
|
|
|
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@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@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@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
>
> --
> http://www.xing.com/go/invita/58469
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JPA: speed vs JDBC
Posted:
Jul 9, 2008 4:43 PM
in response to: Stephen Connolly
|
|
|
What he's really saying is that whether you use JPA or JDBC, you should put a layer of abstraction between the client of the data and the source of the data.
One nice benefit of JPA is, out of the box, it's actually pretty speedy since you get a free second level cache.
You'd have to add in your own cache if you're write pure JDBC.
The cache does have a noticable affect of the "snap" of an application, though it's a two edge sword and can at times be a pain to work with.
|
|
|
|
|
|
|
|
|
RE: Re: JPA: speed vs JDBC
Posted:
Jul 9, 2008 11:34 PM
in response to: Stephen Connolly
|
|
|
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
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
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@gmail.com]
Sent: Mittwoch, 9. Juli 2008 23:28
To: users@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@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@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@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
>
> --
> http://www.xing.com/go/invita/58469
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Re: JPA: speed vs JDBC
Posted:
Jul 10, 2008 1:52 AM
in response to: Markus Karg
|
|
|
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@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@gmail.com]
> Sent: Mittwoch, 9. Juli 2008 23:28
> To: users@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@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@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@glassfish.dev.java.net
>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>>
>>
>>
>> --
>> http://www.xing.com/go/invita/58469
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
RE: Re: Re: JPA: speed vs JDBC
Posted:
Jul 10, 2008 4:44 AM
in response to: Stephen Connolly
|
|
|
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@gmail.com]
Sent: Donnerstag, 10. Juli 2008 10:53
To: users@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@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@gmail.com]
> Sent: Mittwoch, 9. Juli 2008 23:28
> To: users@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@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@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@glassfish.dev.java.net
>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>>
>>
>>
>> --
>> http://www.xing.com/go/invita/58469
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Re: Re: JPA: speed vs JDBC
Posted:
Jul 10, 2008 7:08 AM
in response to: Markus Karg
|
|
|
On Thu, Jul 10, 2008 at 12:44 PM, Markus Karg <karg@quipsy.de> wrote:
> 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.
Ahh no, the difference is the difference between CAN and IS. ASM
_always_ has the potential to be faster than java. Therefore ASM can
be faster than java. Note that this does not imply that ASM _is_
faster than Java. Only that it can be!
>
> 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).
OK, I'll grant you that there _could_ be some crazy O/R mapper that
does not use JDBC... but given that JDBC is the standard mechanism for
accessing databases in Java, and JPA is a Java standard I think the
average temperature of one half of the afterlife will be at or below
273.18K by the time somebody implements such a JPA provider!
>
> 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@gmail.com]
> Sent: Donnerstag, 10. Juli 2008 10:53
> To: users@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@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@gmail.com]
>> Sent: Mittwoch, 9. Juli 2008 23:28
>> To: users@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@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@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@glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>>
>>>>
>>>
>>>
>>> --
>>> http://www.xing.com/go/invita/58469
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: RE: Re: Re: JPA: speed vs JDBC
Posted:
Jul 10, 2008 8:11 AM
in response to: Markus Karg
|
|
|
Hi Markus,
> 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).
No experience with JPA, just JDBC on single server so far.
But thinking about your statement i ask me if this really can be true.
Because there is also an caching mechanism on database level, for example MySQL has the Query Cache.
If i think more about JPA Caching vs Database caching, i also consider how people do caching in bigger application.
Doing this application level with JPA means that the server must inform all server of the cluster on each transaction commit, that some cache objects must be removed or reloaded.
Think its better to cache on database level?
Hammoud
|
|
|
|
|
|
|
|
|
RE: Re: RE: Re: Re: JPA: speed vs JDBC
Posted:
Jul 10, 2008 8:11 AM
in response to: hammoud
|
|
|
Hammoud,
as this is an enterprise computing forum, my assumption is a multi-tiered architecture (JDBC Driver must cross the LAN), as we all have to keep scalability in mind. As a result, the JPA cache is on the client side, while the JDBC / DBMS cache is on the server side. Assuming a JDBC-based JPA implementation, you will benefit from this double buffering (if you have luck, the object is in the client side JPA cache; if you have not so good luck, it is found in the server side JDBC / DBMS cache; if you have bad luck, you must go down to the hard disc). If you do JDBC on the client side, then there is no client cache (unless your particular driver vendor implemented one directly in the client side driver). So, a JPA query will return client side cached objects, while a JDBC query must forward the server side cached data over the LAN. In sum, you have far more LAN transport with JDBC than with JPA. Unless you have client and server on the same machine, what is untypical in Client-/Server computing (that's why it is called Client-/Server  ).
For clustering, things are a bit more complex since there is a difference between pure JPA on the client side and JPA inside of the middle tier (used by Servlet and EJB). You should check e. g. GlassFish's clustering documentation for that. In core, there are three possible scenarios: (a) Do not inform anybody but check for changes revision numbers each time (no need to load object if revision number is unchanged), (b) Shared-All approach: Always write through into the shared disc, (c) Shared-Nothing approach: Inform all cluster nodes after each transaction. What type of cache sync gets used depends on the used product and configuration.
Have Fun
Markus
-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Donnerstag, 10. Juli 2008 17:12
To: users@glassfish.dev.java.net
Subject: Re: RE: Re: Re: JPA: speed vs JDBC
Hi Markus,
> 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).
No experience with JPA, just JDBC on single server so far.
But thinking about your statement i ask me if this really can be true.
Because there is also an caching mechanism on database level, for example MySQL has the Query Cache.
If i think more about JPA Caching vs Database caching, i also consider how people do caching in bigger application.
Doing this application level with JPA means that the server must inform all server of the cluster on each transaction commit, that some cache objects must be removed or reloaded.
Think its better to cache on database level?
Hammoud
[Message sent by forum member 'hammoud' (hammoud)]
http://forums.java.net/jive/thread.jspa?messageID=285687
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: RE: Re: RE: Re: Re: JPA: speed vs JDBC
Posted:
Jul 10, 2008 9:28 AM
in response to: Markus Karg
|
|
|
Hi Markus,
> Client-/Server computing
Have to consider about extending my single server to typical client/server sooner or later:)
> In sum, you have far more LAN transport with JDBC than with JPA
That makes really sense.
Did not include LAN traffic in my consideration.
thanx for clearing my issues,
Hammoud
|
|
|
|
|
|
|
|
|
RE: Re: RE: Re: RE: Re: Re: JPA: speed vs JDBC
Posted:
Jul 11, 2008 12:25 AM
in response to: hammoud
|
|
|
Hammoud,
as soon as LAN comes into play (which is typical in enterprise computing) the performance difference inside of Java VM is by far not your biggiest problem, since LAN is many times slower than you CPU and RAM. That's why I said, architecture and design are the major performance influences, while the actual O/R technology is not. So the actual performance benefit in a real world scenario doesn't come from intrinsic JPA or JDBC benefits, but from the implied architectural or design targets (JPA: client cache, JDBC: server cache). You can find an architecture or scenario that fits pretty well on each of these technologies to proof that it is of higher performance than the other one. So none of these technologies is superior to the other. It solely depends on the use case. That's why I said in the beginning, it is comparin apples and bananas.
Have Fun
Markus
-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Donnerstag, 10. Juli 2008 18:29
To: users@glassfish.dev.java.net
Subject: Re: RE: Re: RE: Re: Re: JPA: speed vs JDBC
Hi Markus,
> Client-/Server computing
Have to consider about extending my single server to typical client/server sooner or later:)
> In sum, you have far more LAN transport with JDBC than with JPA
That makes really sense.
Did not include LAN traffic in my consideration.
thanx for clearing my issues,
Hammoud
[Message sent by forum member 'hammoud' (hammoud)]
http://forums.java.net/jive/thread.jspa?messageID=285715
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JPA: speed vs JDBC
Posted:
Jul 10, 2008 7:06 AM
in response to: bobxu
|
|
|
Hi guys,
I appreciate all these wonderful discussions. They are very very helpful for me, a Java persistence beginner.
I should've provided the usage scenario in the first place.
Data: millions
Tables: tens
Operations: lots of query (with Joins) + potential mass update/insert
After listening to all these advices, I guess I will probably go with JPA for this project.
If the performance is not good as expected (a web page refresh time), then I will try to use native queries which JPA provides. Hope this will work.
Message was edited by: bobxu
|
|
|
|
|
|
|
|
|
Re: JPA: speed vs JDBC
Posted:
Jul 12, 2008 5:15 AM
in response to: bobxu
|
|
|
Hi bobxu,
As you probably noticed your question is a bit too general to give a good answer. If your question is about choosing between a JPA (ORM) or JDBC I think you first have to ask yourself whether your domain is well suited for an object oriented approach. This could be the case when you have many entities with many complex relationships. Or the other way around, if you are using jdbc simply to populate your objects. If this is the case, you are probably better of using an orm for the following reasons:
1) The orm handles all the plumbing code of persisting your object model to the database, which saves you quite some time;
2) All communication with the datastore is done in a consistent and probably thoroughly tested way;
3) The added layer of abstraction helps you creating complex queries. You probably think of queries you want to execute against certain objects, the orm will translate these for you in possibly multiple queries to retrieve all the actual data.
However, since the JPA is an added layer of abstraction I think the biggest problem you will encounter is that you know how to optimize a certain query, but JPA doesn’t let you because it has not provided that feature yet. Maturity of the orm in terms of features you use is therefore very important. I personally use JDO to do all the persistence. It has been around since 2000 and has since then grown very mature. But to give you an example which I encountered regarding performance, in JDO1 you could only explicitly delete objects. This is of course a major performance hit since you first have to retrieve the object before you can delete. Therefore in JDO2, you can use a jdo query which allows you to delete the objects without retrieving and instantiating them.
Now in your case I think it is essential you test how JPA (or any other orm) handles millions of data, both performance an memory wise. Or better, can you tune it as such that you can find a good balance between performance and memory usage. To give an example, is it possible to configure whether size() of a collection (or query result) uses a count(*) to determine this or simply scroll to the last row in your jdbc queries. The first one is better suited for very large collections, the last one is probably faster for small queries.
Hope this helps in decision making,
Christiaan
|
|
|
|
|
java.net RSS
