Hello Helen,

-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Friday 27 June 2003 6:16 PM
To: IBObjects@yahoogroups.com
Subject: RE: [IBO] IBO seems slower for some things compared with the
BDE


At 02:42 PM 27/06/2003 +1000, Peter McLeod wrote:

>Referring back to your earlier advice the application that I am porting,
>doesn't
>have a gazillion active datasets. Most datasets are created dynamically and
>then destroyed when fished, in order to reduce network traffic and conserve
>system resources.

This is by no means a good rule for optimal performance with IB unless a
dataset is wanted only once in the session. The problem with this
technique is that you waste both server resources and increase network
traffic by preparing the statement every time it is used.

Actually that depends on how you create and dispose of the objects that you are using.
You can still prepare and not do it once every time it is used. It would seem from
your comment above that you believe that the object is created used and destroyed
immediately. This is done occassionally for one off things, but not for others.

>Where ever possible I try and use appropriate client server
>design techniques (For instance refer to my article on Delphi 3000. Improve
>Interbase Client Server Performance. I can't always do this as sometimes the
>Boss, prefers things done in a different fashion, but this is not the case
>here).
>In any instance, I would still imagine that IBO would be faster than BDE
>as IBO
>talks direct to the underlying API to achieve it's result.
>
>I also performed the test locally, and found that the BDE was faster than
>IBO.
>Do you have any other suggestions for things to look at?

Having read your article, I would guess that there are probably a lot of
things to look at. Perhaps a good starting place would be the TechInfo
papers, esp. those on transactions. If you *believe* the stuff in your
article about IB indexes, then I'd suspect that you have some problem
indexing to deal with. If you are using Autocommit, then you need to look
at its implications for database performance; and you need to get hold of
some better "facts" about garbage collection.

Having had a quick look across the net after reading your response I rechecked
information about garbage collection and didn't find anything that seemed
contradictory to my views. So maybe you have read something that I havent
(if so please e-mail me the artivle off list. However I note that even some
of the documents on ibphoenix seem to state the same thing http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_tip_perf)As
for indexes, this is from experience, I will check the technical articles,
however if you have any specifically in mind then please e-mail me off list
as this is an IBO list not Interbase (I just don't want to create an off the
topic thread).

Also, I think you would gain a benefit by rethinking your views about
triggers and stored procedures. It's just not true that they cause
bottlenecks on the server! Some people do avoid them because they want
their applications to be portable to a number of different RDBMSs. They do
that at the cost of performance and integrity. In fact, the importance of
enforcing business rules in one and only one place wasn't mentioned in your
article at all.

Actually Helen, I didn't say that triggers and stored procedures were bottlenecks,
in fact I said the exact opposite. Are you reading the correct article? In fact I
even defended them when someone said that they were bottlenecks in the comments
to the article. Now I confess that I never mentioned about enforcing business rules
in one place, but that was because this was an article about Interbase performance.

Anyway, if you are considering moving from the BDE to IBO, then I assume
it's not a vendor-neutral database interface that you are trying to achieve..

It would be a worthwhile exercise to get inside some of the sample apps
that installed with IBO. At least, I uncovered a lot of my own wrong
assumptions when I first worked through those projects...

Currently doing that.

Helen






___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/