On Thu, Jul 10, 2008 at 12:44 PM, Markus Karg <karg_at_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_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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>