Costas Anastassiades writes:

>>> Costas Anastassiades <[log in to unmask]>
10/07/97 12:58pm >>>
Having converted our development databases to IMAGE/SQL, we've ran
a couple
of very simple comparison tests before and after IMAGE/SQL in an
attempt to
quantify any overhead. We're trying to determine if and by how much our
current Transact/iX applications might "slow down" simply by adding the
SQL
interface.

Looking at the CPU total, we find no increase for "read-only" jobs and an
increase of about 10% for "put-and-update" jobs.

-Are these figures about right ? Can anyone confirm ?
-Are there any known situations where we should expect an even
greater
overhead ?
-Is there any remedial action to minimize the overhead ?
-Would concurrent SQL and native accessors place a higher demand on
resources, compared to an equal number of SQL only accessors ?
-------------------------------------------------------------------------------------
I don't think you should expect any change to CPU or to wall time for any
application that continues to access Image via the intrinsics.  A
misconception about Image/Sql is that you convert from TurboImage to
Image/Sql.  There is no such thing.  All you do in the program
Imagesql.pub.sys is let an Allbase DBE know of the existance and
structure of an Image database.  No data is copied into the DBE, and no
pointers, chains or other structures that would need changing are
created in the DBE.  Image intrinsics do not care or even know that the
database is mapped to a DBE.  Indeed the DBE files are not even opened
when doing intrinsic access.

Now, if you start using the Allbase interface either with embedded SQL
statements in your application code, or with a client/server product
(Access, VB, etc.) you will probably not experience the same
performance as native intrinsic access.  Thats because these
applications are talking to Allbase which then determines that the named
table is an Image dataset and then does the appropriate Image intrinsic
calls to open, read, update and write data.  Also, you are dependent on
the Allbase optimizer to determine the access path to get data and to do
locking.  Often an experienced programmer who knows their data can
write better code that the optimizer can, but then YMMV.

I've had about 70 databases, containing thousands of datasets attached
in one DBE for about 2 years now, with no performance problems.

Mike Berkowitz
Guess? Inc.