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@...>
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 ???!
>
> 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