Subject | Re: [IBO] Performance: tIBOquery vs. tIBquery |
---|---|
Author | Helen Borrie |
Post date | 2002-10-14T03:48:14Z |
At 10:15 PM 13-10-02 -0400, you wrote:
using InterBaseXpress (IBX), not IBO.
There should not be a perceptible difference in the performance of SELECT
queries between TIBO* and TIB_*. There will be a significant difference in
the performance of DML queries between using one of these buffered
components and using an unbuffered query component (TIB_Cursor or
TIB_DSQL). You don't need buffering for DML and there are many tasks which
you will speed up by using them instead of a query component.
That apart, on SELECTs, performance is very dependent on the efficiency of
your queries (including very sharp indexing) and the size of result
sets. Result set size is particularly a major issue on slow networks
(incuding the internet). Good performance for Fb/IB also relies on keeping
transaction life as short as possible, a factor that is easier to manage
using TIB_Query. TIB_Query also has better access to some server features
that help to optimise performance; and does not have the extra overhead of
instantiating persistent field objects (TField descendants) for
VCL-compatibility each time the query is prepared. (The TIBO* interface
encompasses both the persistent field object layer and the native IBO
TIB_Row layer of TIB_Column objects).
Helen
>Are there any data on the performance of one vs. the other component,Do you mean TIBOQuery vs TIB_Query? If you are using TIBQuery then you are
>tIBOquery, vs. tIBquery?
using InterBaseXpress (IBX), not IBO.
There should not be a perceptible difference in the performance of SELECT
queries between TIBO* and TIB_*. There will be a significant difference in
the performance of DML queries between using one of these buffered
components and using an unbuffered query component (TIB_Cursor or
TIB_DSQL). You don't need buffering for DML and there are many tasks which
you will speed up by using them instead of a query component.
That apart, on SELECTs, performance is very dependent on the efficiency of
your queries (including very sharp indexing) and the size of result
sets. Result set size is particularly a major issue on slow networks
(incuding the internet). Good performance for Fb/IB also relies on keeping
transaction life as short as possible, a factor that is easier to manage
using TIB_Query. TIB_Query also has better access to some server features
that help to optimise performance; and does not have the extra overhead of
instantiating persistent field objects (TField descendants) for
VCL-compatibility each time the query is prepared. (The TIBO* interface
encompasses both the persistent field object layer and the native IBO
TIB_Row layer of TIB_Column objects).
Helen