Subject | UDF/ reading compressed data is slower then uncompressed data |
---|---|
Author | gbehnke2000 |
Post date | 2004-03-22T10:37:36Z |
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
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