🚀 go-pugleaf

Ok here are the results of my little research into ADO and
ADOExpress

Original problem description:
-----------------------------
Forms in a project I'm involved in were opening too slow. The most
complicated form taking up to 5 seconds to open.

Problem analysis:
-----------------
1. The forms seem to be taking more time to open when there are many
    datasets on the form with many fields in them. The slowest form had
    about 15 datasets with each about 30 fields and 3 of the datasets had
    up to 100 fields. (Note that I'm not describing here how or why it
    came to that form having so many data on it)
2. Adding other form elements doesn't seem to effect the form creation
    time but doubling the number of datasets seems to double the time
    needed for the form to open.
3. The datasets used on that form are TADODatasets which have their
    ADODB.Recordset objects created on the form startup using the
    TADODataset::CreateDataSet() method. Later they are filled with data
    but that is not done until some GUI interaction with the user is done so
    that does not affect us in this case.
4. Tracking to the source I found CreateDataSet() calls to be the culprit.
5. Creating the same ADODB.Recordset objects in VB was done pretty
    much instantly (under 20 miliseconds).
6. Creating the recordsets directly using ADO in C++ builder achieved
    the same performance.
7. Tracking the VCL source code led me to the
    TADODataSet::InternalInitFieldDefs() method - particularly to the
    creation of the TFieldDef objects for integer fields.
8. Profiling showed that that the F.Properties[SIsAutoInc] call in that
    method was taking too long. F here is a pointer to the ADODB.Field
    COM object. Properties has a default array property Items which takes
    a wide string or an integer as a parameter and returns a pointer to the
    ADODB.Property object.
9. This call is used on integer fields to check whether the field in
question
    has the autoIncrement flag set or not. In this project no autoIncrement
    fields are used. That property is automattically added to all fields by
    ADO on field creation - that was checked from VB as well as BCB.
10. More precisely accessing that property was slow, and whether it was
    accessed by index or by name didn't make a noticable difference. The
    only thing that made a difference was the total number of fields in the
    recordset. From that I guess that all the propertys for all the
recordset
    fields are kept internally in one big datastructure not too well
optimized
    for looking up one given property.
11. The same behavior was duplicated in VB just to make sure that it had
    nothing to do with ADOExpress TADODataSet wrapper implementation.

Solution:
---------
1. I copied the ADODB.pas VCL unit to the project and modified it so
    setting up autoincrement flags for the recordset fields can be removed
    on compilation using a precompiler directive and made the project use
    that version of TADODataSet wrappers.

Results:
--------
1. The speed at which many of the forms in the project open has been
    drastically increased. Dropping the time needed to open the most
    complex form from 5 to under 1 second.
2. The difference between the time needed to directly create the
    ADODB.Recordset objects needed and the time needed to create
    the ADODB.Recordset objects through ADOExpress seems to
    suggest that there are further unnecessary parts of ADOExpress that
    can be optimized or removed if unnecessary. No other uses of the
    ADODB.Recordset's Properties collection were found in
    ADOExpress.

If anyone knows any place that this kind or similar information on ADO
objects and ADOExpress can be found I'd be more than grateful if you
could point it out for me.

Hope this helps someone...
    Jurko