| Subject | Re: [IBO] for Jason: TIBOQuery vs. TFIBDataset speed test |
|---|---|
| Author | Lester Caine |
| Post date | 2005-05-25T20:36:24Z |
Jason Wharton wrote:
machines take 12 and 29 seconds for the IBO version to open, and less
than 1 and 3 seconds for the IBO.
My own machine takes 8 seconds against less than one second. I would not
be too worried about the 8 seconds, but I can see the problem.
There are a lot of tables and fields, so SchemaCache should help with
opening times? But after 24 seconds while building cache, the opening
time goes UP to 14 seconds.
I think that there are a couple of tables that are particularly slow,
but I have not had a chance to look closer yet - and I'm off on a weeks
holiday in 36 hours time ;)
The main point that I would make is that when you START the program, you
should not need everything open. In fact you don't want everything open.
I just open the queries that I need to populate current display. I also
trim all unnecessary fields, so that I only have the ones actually
needed ( not sure if that applies in your case Enrico, but if converting
from BDE type setup, there tends to be a lot of 'slack' that can be
trimmed ).
As you progress to other pages, the necessary additional queries are
built, and opened, and only get closed when not needed. Once prepared,
just changing parameters helps keep the speed up.
IBO is building an internal cache of data that FIB does not which
accounts for a lot of the delay. The SchemaCache helps a lot when you
are working over slow links, but here as we can see it is apparently
hindering things - and *I* want to have a look at why that is. But some
of my systems work over 64kB links, so anything that cuts down network
traffic ...
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
> As I said earlier, where IBO may be slower than the other competitor'sOK Enrico has supplied a sample program built with FIB and IBO. His own
> products is in the time to prepare statements. If there are hordes of query
> objects and you are having them prepared ahead of time (which is fine in
> most cases) then IBO is going to come in a bit slower. However, once the
> wait is over, then IBO should be much snappier and more interactive when
> configured and used correctly.
machines take 12 and 29 seconds for the IBO version to open, and less
than 1 and 3 seconds for the IBO.
My own machine takes 8 seconds against less than one second. I would not
be too worried about the 8 seconds, but I can see the problem.
There are a lot of tables and fields, so SchemaCache should help with
opening times? But after 24 seconds while building cache, the opening
time goes UP to 14 seconds.
I think that there are a couple of tables that are particularly slow,
but I have not had a chance to look closer yet - and I'm off on a weeks
holiday in 36 hours time ;)
The main point that I would make is that when you START the program, you
should not need everything open. In fact you don't want everything open.
I just open the queries that I need to populate current display. I also
trim all unnecessary fields, so that I only have the ones actually
needed ( not sure if that applies in your case Enrico, but if converting
from BDE type setup, there tends to be a lot of 'slack' that can be
trimmed ).
As you progress to other pages, the necessary additional queries are
built, and opened, and only get closed when not needed. Once prepared,
just changing parameters helps keep the speed up.
IBO is building an internal cache of data that FIB does not which
accounts for a lot of the delay. The SchemaCache helps a lot when you
are working over slow links, but here as we can see it is apparently
hindering things - and *I* want to have a look at why that is. But some
of my systems work over 64kB links, so anything that cuts down network
traffic ...
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services