Joe Sam Shirah wrote:
> Hi Jon,
>
> I would take your experience over many others, but it seems to me
> that Craig, as usual, is right on on this topic. Does it make sense to
> you for client code to be 4+ times faster than server code? ( I'm sure
> you used marketer's exageration for the order of magnitude, which
> would be 10x, but you didn't include the all purpose get-me-out-of-this
> asterisk. 8-) ) This is not a common experience. Sounds like there
> might have been some locks, or else the "perfectly good code" was in
> some bad sequence or hit tables in the wrong order. Even if this
> happens to be the case in Oracle, that's Oracle's problem and isn't
> generally true. Also, don't forget data integrity issues that can be
> ensured in one place by SPs, where otherwise they have to be
> enforced on a per program basis**. ( ** = yes I know about triggers,
> but from the perspective we are talking about, there is no difference
> between triggers and SPs, other than scope of ops, generally. )
>
> I am less of a stored procedure fan than I used to be, but that's due
> to portability issues. I certainly don't want everyone out there deciding
> to move from stored procedures to straight JDBC to achieve an order
> of magnitude* speed increase without LOTS more evidence.
>
> Joe Sam Shirah
> Autumn Software
>
I appreciate your vote of confidence, but there's a warning here ... do not
believe *ANY* benchmark that is not based on your own application, or something
provably close to it. Benchmarks of all sorts, but most especially trivial
test cases, are going to be misleading. The worst thing to do, IMHO, is to
make generalized judgements such as "technology A is better than technology B"
based on simple, out-of-context, examples like this.
Both Jon's experience and mine were real, and therefore valid. That's why
there is often more than one way to solve a problem. There's also more than
one problem to solve. Performance is important in many (probably most) apps,
but time to market, ease of maintenance, and/or portability can also be in many
circumstances. Any of these may be valid reasons to choose a soluition that,
on the surface, may appear slower.
It is our responsibility as software designers to choose the solution that best
balances *ALL* of the requirements. Trust me ... in the almost 30 years since
I wrote my first BASIC program, this is the most important lesson I've ever
learned about software design.
Craig McClanahan
>
> -----Original Message-----
> From: jon * <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Monday, June 14, 1999 8:56 PM
> Subject: Re: stored procedure in servlet!
>
> >> My experience with stored procedures is that they help quite a bit
> >(performance
> >> wise) if you do lots of database interactions inside the stored procedure
> >(such as
> >> updating a number of related tables).
> >
> >Maybe it was just our (clear ink's) PL/SQL guru that was working for us,
> but
> >our experience was just the opposite. We had a rather large stored
> procedure
> >that worked against a number of tables (this was a highly normalized
> >database) and we re-wrote the same code as a java method and the java code
> >was an order of a magnitude faster. (ie: it went from like 60+ seconds to
> >like 15 seconds to do exactly the same thing). I do trust that our guru's
> >code was good (I looked at it myself) but you never know. ;-)
> >
> >On top of it, we had heard similar things from people within oracle about
> >the performance of pl/sql not being that great, especially under high
> >concurrency loads.
> >
> >-jon
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
