--- In firebird-support@yahoogroups.com, "Ivan Prenosil"
<Ivan.Prenosil@s...> wrote:

> 1)
> Did you find out where the slow down take place ? It can be either
>
> * SELECT ... WHERE ...
> * SP
> * UDF
> * transfer of blob to client
>
>
> 2)
> > By the way i found the following the bug:
> > If the last parameter of the parameter list is NULL what means

that

> > the Databasefield is NULL, FB crash !!
>
> It is old bug that is already logged [544132].
> When the last parameter is NULL, and UDF returns either BLOB
> or parameter BY DESCRIPTOR, then blob structure (or dsc structure)
> of that output parameter will not be correctly initialized -
> it usually means that pointer to put_segment function wil be zero

(nil),

> and thus calling put_segment will crash server.
>
> Ivan
>
>
> ----- Original Message -----
> From: "gbehnke2000" <Behnke@h...>
> To: <firebird-support@yahoogroups.com>
> Sent: Monday, March 22, 2004 11:37 AM
> Subject: [firebird-support] UDF/ reading compressed data is slower

then uncompressed data

>
>
> > Hi Members,
> >
> > i have the following problem. To reduce the reading time from my
> > database in the case of slow line connections (mobile phone) iw

rote

> > a UDF which adds some fields inlcuding a blob field to one stream
> > which is also compressed.
> > Here is the Header of the udf written in c
> >
> > _BLOB DLL_EXP fn_compress_doc( ARG(_BLOB, _sourceBlob),
> > ARG(char*, _ERNA_Leitung),
> > ARG(char*, _ERNA_Aufgeber),
> > ARG(char*, _ERNA_Prioritaet),
> > ARG(char*, _ERNA_Adressen),
> > ARG(char*, _Absender),
> > ARG(char*, _CodePage),
> > ARG(char*, _LINKTOBASIS),
> > ARG(char*, _DocName),
> > ARG(_BLOB, _sResult))
> >
> > in a stored procedure (FROM READ_DOC_C) i call this udf with
> >
> > SELECT compress_doc(TEXT_RTF,
> > ERNA_Leitung,
> > ERNA_Aufgeber,
> > ERNA_Prioritaet,
> > ERNA_Adressen,
> > Absender,
> > CODEPAGE,
> > LINKTOBASIS,
> > DocName),
> > CREATE_TIME,
> > LINKTOCHANGE
> > FROM STAR_Document
> > WHERE
> > GUID_CHANGE=:GUID
> > into :TEXT_RTF,
> > :create_time,
> > :LINKTOCHANGE;
> >
> > The udf works fine and the compression rate is very high
> > And now my surprise the old way
> >
> > SELECT TEXT_RTF,"\
> > "ERNA_Leitung,"\
> > "ERNA_Aufgeber,"\
> > "ERNA_Prioritaet,"\
> > "ERNA_Adressen,"\
> > "Absender,"\
> > "Ressort,"\
> > "DocName,"\
> > "CREATE_TIME,"\
> > "LINKTOBASIS,"\
> > "LINKTOCHANGE,"\
> > "CODEPAGE"\
> > " FROM STAR_Document "\
> > "WHERE GUID_CHANGE=?GUID"
> >
> > is faster then working with the udf
> > SELECT * FROM READ_DOC_C(?GUID)"
> >
> > In my software i make a trace during the reading operations and

here

> > the result
> >
> > classic way
> > 2004-03-22-10.31.15 ERNA Header readed in 2.86 s // all fields
> > except the blob (TEXT_RTF)
> > 2004-03-22-10.31.15 start to read Blob
> > 2004-03-22-10.31.21 Blob with 7508 Bytes readed (not forget ist
> > uncompressed !)
> > 2004-03-22-10.31.21 in 5.86 s
> >
> > and here the new way with udf
> >
> > 2004-03-22-10.40.18 ERNA Header readed in 2.82 s // only the
> > fields "create_time, LINKTOCHANGE"
> > the other fields are appended in my udf to the blobfield and will

be

> > seperate in my client software
> > 2004-03-22-10.40.18 start to read Blob
> > 2004-03-22-10.40.25 Blob with 2109 Bytes readed // as you can see

is

> > highly compressed
> > 2004-03-22-10.40.25 in 6.71 s
> >
> > What happens ???!
> > Ivan,

thanks for your response.
Might be there were some differences between the mobil connections.
I repeated my test more times and now the compressed version is
indeed faster. But not so as i expected. I must mentionend that we
make our remote access over a Cisco with Softwarecompression too.
Here my traced results:

with compression from my UDF

2004-03-22-15.40.03 Blob with 2112 Bytes readed
2004-03-22-15.40.03 in 6.71 s

and without compression of my udf

2004-03-22-15.58.40 Blob with 7508 Bytes readed
2004-03-22-15.58.40 in 7.64 s

measured on my client. That means that i only save one second,
although the blob field are compressed to 1/3 of the regular size.
I could also measure that the exeute command
IB_DSQL->Execute();
needs with both versions nearly 3 second.
Is there a way to decrease this time ?
The same is true for the prepare command which needs more then 4
seconds
IB_DSQL->Prepare();
Is there also a way to decrease this time ?
In my opinion i think that are some ip packages will be necessary to
perform this operations.
I work on the client side with IBO Objects. Would it better to use
the Firebird API directly ?

Many thanks in advance
Gerhard

> > By the way i found the following the bug:
> > If the last parameter of the parameter list is NULL what means

that

> > the Databasefield is NULL, FB crash !!
> >
> > Best regard Gerhard