Re: java stored procedures fast, but slow when called as SQL function

Following up on Peter J. Holzer, 20 Apr 2003:

>
> Sun would probably complain if they ditched the jdbc classes altogether
> and replaced them with oci classes.

and that would be the easiest and most direct way to make Java faster inside Oracle, BTW. The jdbc layer is completely unnecessary if one puts the JVM inside the database code. Unfortunately (or fortunately, depending on the point of view!) Sun won't allow that to happen. Microsoft themselves tried to do something similar and ended up in hot water. Sun has a long history of shooting themselves on the foot for the wrong reasons, nothing new...

> Also, from some discussions in this group I understand that Oracle has
> thrown out all the EJB stuff out again in 9i.

Not again and not exactly out. They just moved it to 9iAS. Which is where it should have always been, IMHO. I can't see how the J2EE EJB model could ever work the way it is supposed to work if it's inside a database. It just can't be as scalable as J2EE is supposed to. RAC notwithstanding.

>
> A "context switch" normally means switching to a different process. That

Normally. But when you have huge bodies of code like the JVM and the Oracle SQL and PL/SQL code, with huge stack and data areas, any jump from one to the other will always invalidate every single pipeline and local paging you may have in the current CPU.

And invalidating those in a modern CPU is roughly equivalent to slowing it down to a 100MHz 486. The only way for modern CPUs to get the speed they get is to rely on serialization of execution and extensive pipelining. You start jumping around and you got a huge performance problem in your hands.

Incidentally, people often say "code bloat" is a characteristic of modern applications. It really isn't added code in most cases. Just the result of optimizing compilers: they repeatedly inline library calls to enable pipelining and maximum local cache hits.

A piece of code that ten years ago might compile into a 1M executable with many calls to library code nowadays gets compiled into a 10M executable with that same library code inlined all over the place. I've had a few surprises that way with old C code I had when re-compiled with the latest optimizing stuff.

>
> Neither will I. Now, if Oracle integrated a perl interpreter into the
> database would be different <gd&r>

You got my vote! And I'll cast another one for Pascal. Although I reckon my chances there are pretty average... But it would make sense for Oracle: free, standardized language, with a long following in academia, not much commercial competition, what more could one ask <nudge, wink>. :D

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam