Re: Trying to decide whether to support DB2 or Oracle

Larry wrote in message <3AF73095.C03CBF27_at_us.ibm.com>...
>Marc,
>
>I don't know what the product plans are in terms of the requirement for the
 "C"
>compiler. But there is another side of this that I respectfullly submit you
 are
>completely ignoring: performance. How would an interpretive SQL stored proc
>perform vs. an IBM SQLPL "compiled" stored proc, for a reasonably complex
 stored
>proc? I really don't know ... I'm just asking. But I'll bet that the
 compiled
>stored proc would tend to perform better.
>
I can't (necessarily) agree with that. If the C compiled stored procedure did a lot of looping and integer maths or stringish activity, then it has a chance. But that's not your typical sp.

But consider any sp which actually does things like selects, inserts, index searches etc. Even C compiled code will be making bucket-loads of calls upon engine routines and no amount of C code can influence the presumably optimised engine code which is burning millions of cycles and disk rotations on your behalf.

Arguing that compiled is faster than pcode for high level and very-high level languages is not a very productive argument.

I've written Perl and Icon utilities which execute either at the same speed or occasionally faster than C. The reason is two-fold - either the algorithm is I/O bound anyway, or when the speed comes out faster, it's because the high-level language allows the choice of a much better algorithm. The coding time required to regain and perhaps exceed the speed the high-level language would definitely not be worth the effort.

Claims of higher performance from compiled code should be backed up with hard figures. Received on Tue May 08 2001 - 01:46:01 CEST