SEO

DB2 has a concept of fenced and non fenced process for Stored procedures.
Doesn't Informix also has the same concept for UDFs in 'C'.

we use datablades (in 'C') and run the stored procedures as a separate
VP so that an errant code does not bring down the instance.

VPCLASS sp,num=3 # Number of JVPs to start with

Is there a performance penalty in this. The communication between
the SP VPs and CPU vps has to be via some inter process communication.
If SPs run in the CPU VP itself, is that overhead eliminated? We have
a very well tested SP code running for months. Will it benefit by running
them in CPU VPs.

Ravi

"rkusenet" <rkusenet@sympatico.ca> wrote in message news:<bm3lpv$iha8b$1@ID-75254.news.uni-berlin.de>...
> DB2 has a concept of fenced and non fenced process for Stored procedures.
> Doesn't Informix also has the same concept for UDFs in 'C'.
>
> we use datablades (in 'C') and run the stored procedures as a separate
> VP so that an errant code does not bring down the instance.
>
> VPCLASS sp,num=3 # Number of JVPs to start with
>
> Is there a performance penalty in this. The communication between
> the SP VPs and CPU vps has to be via some inter process communication.
> If SPs run in the CPU VP itself, is that overhead eliminated? We have
> a very well tested SP code running for months. Will it benefit by running
> them in CPU VPs.

1. A DB2 fenced UDF runs in an address space that is isolated from the
DB2 kernel. In addition to safety, this approach lets you do all kinds
of things in your DB2 UDF that would otherwise cause problems.

2. The "named VP" approach of IDS is not quite the same thing as the
fenced UDF, but it has its own set of pros and cons. If your IDS UDF
commits a mortal sin (SIGSEGV, SIGBUS, or their equivalents on other
platforms) it will (almost certainly) not crunch the entire IDS server
process: only the VP. *BUT* unlike the DB2 case, you have to work a lot
harder to get a memory leak in IDS (if you're using the mi_XXX calls).
In IDS the engine takes care of the allocation and freeing of memory.

3. There is some overhead to the fenced UDF or named VP approaches as
they both require a process context switch into & out of the process
within which the UDF runs. If your UDF is small & cheap, the switch can
make a *big* difference. But if your UDF is big, or of it does a lot
of I/O (talks to a BLOB), then the relative difference becomes
insignificant.

4. There is surprisingly little difference between the calling overheads
of a small 'C' UDF and a small SPL UDF. My advice to anyone who'll
listen is to do the minimum of gnarly, computationally expensive and
general purpose stuff in 'C', and then to re-use the 'C' UDFs in
SQL and SPL. If what your doing is a stored procedure (ie. if it
contains SQL) then do it in SPL, because the performance differences
between 'C' and SPL are non-existant (the SQL cost overwhelms everything
else) and 'C' is, well, nasty.

(BTW: Note that distinction; a UDF contains no SQL, but a stored procedure
does. Stored procedures or UDFs can be implemented using either the
CREATE FUNCTION or CREATE PROCEDURE syntax, so this is a design
difference, not a syntactical difference.)

But your mileage may vary. And my knowledge of the relative overheads of
function calls in IDS dates to version 9.3.

KR

Pb