Version 4 slower than 3.4.6?

[Kristoffer]

We recently upgraded to version 4 and found that all of our queries now run slower than they did with 3.4.6. When using a TOracleQuery and changing the parameters to insert different valued records we see about a 20% decrease in performance.

 

[Marco Kalter]

Performance should be the same. Can you let me know your Oracle Client version?

------------------
Marco Kalter
Allround Automations

 

[Kristoffer]

I am using Oracle 8.1.7.

 

[Holger Dors]

I'm seeing also a performce loss after updating to 4: using a test application, it used approx. 23 secs previously, now it's up to approx. 33 secs.

I'm using Oracle 8.1.7 as well.

Any idea what could causing this?

 

[Marco Kalter]

Note that 4.0 can select a different Oracle Home than 3.4. If you have multiple Oracle Homes, you may want to verify this.

Perhaps you can also use the Oracle Monitor to find out if there are one or more queries that take significantly longer?

 

[Bernhard Geyer]

I've update to the last 4er-Version in the last days and I also see a slow-down of the performance.

The time for a "bulk"-import raises from 36s to 48s (Many small selects's an imports).

Any new infos for this slow-down?

 

[Marco Kalter]

We have not been able to reproduce any speed differences.

 

[Bernhard Geyer]

Hi,

I've found the reason for this difference
(Using Oracle 8.1.7 Client&Server):

In Methode TOracleQuery.InternalDescribe when getting the infos for the fields, in V4 DOA gets the info for CharSize and CharSet from the database.

Unit Oracle.pas
Line 7631: Getting CharSize
Line 7635-7640: Getting CharSetFrom.

When profile the Unit with AQTime (Line-Profiling, I get that about 88% of the Function-Time take the line 7631 (Getting CharSize).
Comment this line out and you get the performance as it was with V3.4.

But I'm asking myself why there is no caching of such Field-Infos? Every time when the field x from table y is in a query, the infos of the fieldsize, type, ... is retrieved from the database. When such Info are cached, you can get this info without any performance-problems.

 

[Marco Kalter]

Maybe this is an 8.1 client or server bug. We'll check it out.

 

[Bernhard Geyer]

If found some explanation
(http://www.lc.leidenuniv.nl/awcourse/oracle/appdev.920/a96584/oci06des.htm):

Client and Server Compatibility Issues for Describing

When an Oracle9i or later client talks to an Oracle8i or earlier server, it will behave as if the database is only using byte length semantics;

When an Oracle8i or earlier client talks to a Oracle9i or later server, the attributes OCI_ATTR_CHAR_SIZE and OCI_ATTR_CHAR_USED are not available on the client side.

In either case, the character length semantics cannot be described when either the server or client has an Oracle8i or earlier software release.

I think in this cases this function shouldn't be called.

 

[Marco Kalter]

Thanks for the extra info, we'll verify this and will fix it is appropriate.

 

[Bernhard Geyer]

Any new Info?
Does my Fix work as expected?

 

[Marco Kalter]

Yes it does. If anyone needs a fix, let me know.

 

[Jens Fudickar]

Yes please!

 

[Marco Kalter]

If you let me know your Delphi/C++Builder version, I will upload the corresponding package.

 

[Jens Fudickar]

D7 and D2005.

Greetings
Jens