Subject | TIBOQuery vs. TIB_Cursor |
---|---|
Author | brian_nuckels <bnuckels@midrid.com> |
Post date | 2003-02-12T20:52:02Z |
I have some performance issues I'd like to pick people's brains on.
I'm working on an ASTA application. Asta is a middleware component
suite. I started off using dbExpress and have now decided I'm going
to switch to IBO. I profiled my app server and found a bottleneck
calling GEN_ID. IBO was noticably faster than dbExpress, though not
by a huge amount. I decided it might be worthwhile to create a
testbed application and do some more profiling.
I found IBO to be almost 3 times faster on inserts, using TDSQL vs.
TSQLDataSet. If you are interested, I posted a graph at
http://groups.yahoo.com/group/IBObjects/files/InsertPerformance.jpg
This test case was inserting 1000 single-field NUMERIC(18,0) rows
with each of the component suites. All queries are paramerized and
prepared.
I moved on to selects. Here, I found that using TIB_Cursor, IBO and
dbExpress were dead even on selects. But, using TIBOQuery, IBO was
significantly faster (even with UniDirectional=True and
ReadOnly=True).
The reason this is an issue is that Asta has something anologous to
TProvider called TAstaProvider, and this must hook-up with a TDataSet
derived component. TIBOQuery is TDataSet derived, but much slower
than TIB_Cursor. Is there anything that can be done about this? My
thoughts about this are that it may be caused by the fact that
TIBOQuery wraps a TIB_Query as opposed to a TIB_Cursor, but this is
done at the TIBODataSet level, so there's nothing I can do about this.
If you want to see the graph on the select test results:
http://groups.yahoo.com/group/IBObjects/files/SelectPerformance.jpg
This test was done by selecting, one at a time, 1000 records from the
same table that inserts were performed on above with each of the
component sets.
Since the improvements on inserts are so significant, and my
application is write-intensive, it is worth the effort for me to
convert to IBO at this early stage. But I'd love to find a way to
get IBO on-par with dbExpress for SELECTs.
I will investigate some more in the direction of the TIB_Query and
see if that's where the problem lies.
Thanks,
Brian Nuckels
PS--if you are curious, the graphs were produced by AQTime
I'm working on an ASTA application. Asta is a middleware component
suite. I started off using dbExpress and have now decided I'm going
to switch to IBO. I profiled my app server and found a bottleneck
calling GEN_ID. IBO was noticably faster than dbExpress, though not
by a huge amount. I decided it might be worthwhile to create a
testbed application and do some more profiling.
I found IBO to be almost 3 times faster on inserts, using TDSQL vs.
TSQLDataSet. If you are interested, I posted a graph at
http://groups.yahoo.com/group/IBObjects/files/InsertPerformance.jpg
This test case was inserting 1000 single-field NUMERIC(18,0) rows
with each of the component suites. All queries are paramerized and
prepared.
I moved on to selects. Here, I found that using TIB_Cursor, IBO and
dbExpress were dead even on selects. But, using TIBOQuery, IBO was
significantly faster (even with UniDirectional=True and
ReadOnly=True).
The reason this is an issue is that Asta has something anologous to
TProvider called TAstaProvider, and this must hook-up with a TDataSet
derived component. TIBOQuery is TDataSet derived, but much slower
than TIB_Cursor. Is there anything that can be done about this? My
thoughts about this are that it may be caused by the fact that
TIBOQuery wraps a TIB_Query as opposed to a TIB_Cursor, but this is
done at the TIBODataSet level, so there's nothing I can do about this.
If you want to see the graph on the select test results:
http://groups.yahoo.com/group/IBObjects/files/SelectPerformance.jpg
This test was done by selecting, one at a time, 1000 records from the
same table that inserts were performed on above with each of the
component sets.
Since the improvements on inserts are so significant, and my
application is write-intensive, it is worth the effort for me to
convert to IBO at this early stage. But I'd love to find a way to
get IBO on-par with dbExpress for SELECTs.
I will investigate some more in the direction of the TIB_Query and
see if that's where the problem lies.
Thanks,
Brian Nuckels
PS--if you are curious, the graphs were produced by AQTime