Re: Benchmarks - Java vs PL/SQL

Yeah or one of those pesky E-Commerce applications like amazon that perform simple queries millions of times a day.

In article <t4818m5dbjpta2_at_corp.supernews.com>,   "Richard Sutherland" <rsutherland_at_In-Touch.net> wrote:
> You are absolutely correct. So, for those several thousand
 applications out
> there that spend most of the week querying DUAL, you'd better use
 PL/SQL.
>
> Richard
> rvsutherland_at_yahoo.com
>
> <jdarrah_co_at_my-deja.com> wrote in message news:920l21$49
 $1_at_nnrp1.deja.com...
> > I agree that its important to write effiecient SQL but for
 applications
> > that are transaction and query intensive, bad data access will kill
> > performance. In the test I conducted 10,000 iterations
 of "select 'X'
> > from dual" took 7.5 sec in a java stored procedure vs .15 in
 PL/SQL. I
> > doubt even the sql savvy technician could hint the above statement
> > enough to put java stored procs over the top.
> >
> > In article <t47hfvhs05nr80_at_corp.supernews.com>,
> > "Richard Sutherland" <rsutherland_at_In-Touch.net> wrote:
> > > Actually, the "data access advantage" has little to do with this
 whole
> > > subject. What REALLY matters is the SQL written. Lousy SQL sent
 to
 the
> > > database in 0 nanoseconds is still going to lose to the savvy SQL
> > > technician.
> > >
> > > Richard Sutherland
> > > rvsutherland_at_yahoo.com
> > >
> > > <jdarrah_co_at_my-deja.com> wrote in message
> > > news:91vtfc$cfs$1_at_nnrp1.deja.com...
> > > > The artical you mention glosses over one very important point.
 To
> > > > quote Larry:
> > > > "It was not the goal of these tests to examine any specific
 data-
 access
> > > > API or transport which may offer an "data access advantage" to
 one
> > > > specific language platform over another (e.g. JDK 1.2.2 with a
 native
> > > > JDBC driver might be able to access the database more
 efficiently
 than
> > > > JDK 1.1.7 using an ODBC-bridge)."
> > > >
> > > > The primary purpose of most database applications that I have
 been
> > > > involved with is to select information from the database,
 display
 it to
> > > > a user, and allow that user to manipulate the data. In cases
 like
> > > > this, the most important performance metric IS the data-access
 API.
> > > > Larry's performance tests miss the forest for the trees. I have
 little
> > > > doubt that java can run circles around pl/sql with number
 crunching
 and
> > > > string manipulation tasks but that won't really matter if the
> > > > application is spending 99% of the time waiting on the jdbc
 layer to
> > > > return the data to be crunched.
> > > >
> > > > In article <3A42AAA3.3020009_at_interealm.com>,
> > > > Roby Sherman <rxsherm_at_interealm.com> wrote:
> > > > > Avi Abrami wrote:
> > > > >
> > > > > > I am looking for some performance
> > > > > > measurements/comparisons for stored
> > > > > > procedures in PL/SQL versus stored
> > > > > > procedures in Java.
> > > > > >
> > > > > > We are trying to decide whether it is
> > > > > > better to write our stored procedures
> > > > > > in Java or PL/SQL.
> > > > > >
> > > > > > TIA,
> > > > > > Avi.
> > > > > >
> > > > > >
> > > > > Try http://www.orageeks.com/technotes/larry/languages.html
> > > > >
> > > > > --Roby
> > > > >
> > > > >
> > > >
> > > >
> > > > Sent via Deja.com
> > > > http://www.deja.com/
> > >
> > >
> >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
>

Sent via Deja.com
http://www.deja.com/ Received on Tue Dec 26 2000 - 10:33:21 CST