isc_segstr_eof not set in first call to isc_get_segment()
---------------------------------------------------------

                 Key: CORE-6184
                 URL: http://tracker.firebirdsql.org/browse/CORE-6184
             Project: Firebird Core
          Issue Type: Bug
          Components: API / Client Library
    Affects Versions: 3.0.4
            Reporter: Cris Doorn


When you read a blob and all data is returned in the first call to 
isc_get_segment(), both the returned status and the status_vector[1] remain 0.

Since most people will keep reading the blob-data while the status equals 0 or 
the vector equals isc_segment, like this:

while (blob_stat == 0 || status_vector[1] == isc_segment) { 
  isc_get_segment()
}

a second call to isc_get_segment() is made. This second time it does indeed 
return isc_segstr_eof in status_vector[1].

Although this might seem totally harmless, it really isn't because it affects 
the performance very badly.
The second call to isc_get_segment(), returning no data at all, thus only 
returning isc_segstr_eof, is far more slower than the first call to 
isc_get_segment().

By using the actual blob size retrieved with isc_blob_info(), the read loop can 
be modified so that it stops reading when all data is retrieved. 
This prevents the extra, very slow, call to isc_get_segment()


To give an impression of the impact, we'll fetch 1000 rows with each 2 small 
blobs subtype 1. 

The original code with 2 calls to isc_get_segment() for each blob, took 7575 ms
After removing the second call to isc_get_segment(), it only took 448 ms.

Without the extra call, the code runs about 17 times faster!


Returning the isc_segstr_eof directly in the first call when all data is 
returned seems like the fastest solution to me.
This also prevents a second round trip over the network.
Fixing the reason why the second call is so much slower might also be great. 


Kind regards,
Cris





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to