Zeoslib Portal

Hi,

Did anyone performed some performance measurements with Zeos, UIB, IBObjects, ...

Thanks!

There are lots of functions in Zeos that can be improved in speed. I'm currently introducing thousands of "const" key words for string, Variant, TZVariant and dyn. array parameters what eliminates the compiler magic's reference counting-try/finally blocks. But that meight still take days or weeks due to the amount of lines of code that I have to alter.

Hi,

We are building a big commercial application based on ZeosDBO and Firebird 2.x. Unfortunatelly as the database growed, the first performance problems occured. Opening a query is extremly slow. I have tried to open the same query with EMS (a database client for Firebird). The results are:
- Opening the query with EMS took approx 1 second.
- Opening the query with ZeosDBO took approx 6 seconds.

When opening the query with ZeosDBO, I have turned on the SQLHourGlass of TZConnection. I have experienced that the mouse cursor blinked after the first second. I suppose that opening the query took 1 second for ZeosDBO, and the additional 5 seconds were for reading the whole resultset.

My questions are:
- Is my assumption right?
- If it is right, how can I tell TZQuery, not to read the whole resultset, but read only on demand.

Thanks,
Laszlo

Hi,

I have made further investigations...

In my last post I have not told that I use a DBGrid component to browse the data of the grid. The DBGrid components call RecordCount. I have checked the source code of ZeosDBO and found that the GetRecordCount method is implemented in ZAbstractRODataset.pas in a very common way. It iterates through the records of the resultset and counts them. This is a very slow solution, because it reads all the data of a resultset from the server. I have checked the descendants of ZAbstractRODataset and found that only the ADO driver has specialized implementation (that is might faster)...

A workaround (that I have found in this forum, but in an other topic): set the filtered property to true. This way the grid won't call RecordCount (due performance reasons - same as above), and the opening of a query will be faster.

Greets,
Laszlo

And of course, we are very willing to accept a specialized Firebird implementation of Recordcount as well... Just check if that's possible for the FB API.
Not all databases (e.g. Mysql ) can do it as far as I know. That's why it's implemnted in this general way.
Just remember : firing a seperate 'select count' with the same from/where part is not an acceptable solution.

Mark

Out of curiosity why isn't firing a seperate 'select count' with the same from/where part an acceptable solution?

Because it's almost twice the work for the server. Which isn't a problem for a primary key lookup, but with a serious join and some stored functions as part of your query you wouldn't like that. Also : it may be wrong anyway when your queries are time dependent or when other users are updating on the same table (depending on Transaction Isolation level).
But of course, when it's not a problem for your situation you could implement that yourself, eg by extending the component.

Mark