Performance and layer overhead

The performance of ADOExpress has been discussed quite a lot in this
newsgroup. I suggest that the problem lies in the multitude of layers
required to get from a DataAware control down to the 'data'. Please bear
with my rather lengthy discussion.

Mark Edington in news:7tbfr4$ states that there is a
15% to 20% degradation when using TADODataset rather than using ADO
directly, 50% or more if you read the data. To some 20% may be acceptable,
to most I think it is a problem.

The current hierarchy is:


Obviously from Data to ADO we have no control over, however from ADO to
TDataAwareControl we do. This hierarchy has evolved from the BDE, Delphi 4
introduced TDataSet as 'the virtualized base class for all dataset
components that represent data in rows and columns.' From the help file:
'TDataSet encapsulates a database-engine independent set of properties,
events, and methods for working with data.'

This is where the problem lies, ADO already does all that. We have been
writing in-house DAO and ADO TDataset descendents for a long time now, and
the mapping from ADO to TDataset is reasonably simple, most of the calls are
simply passed on to ADO. The effect is that you have a database independent
class on top of another dataset independent class hence the performance

So what can be done to this? As I see it, ADO provides the interface to the
data, there is no need to build a class on top of it. We need either a new
set of data aware controls that link directly to the ADO Classes, or to be
'backward' compatible add new capabilities to the existing controls.

I know it is a lot to ask Borland to make a clean break with their beloved
BDE and TDataset class, but I am sure they will win more friends than
enemies by providing a new clean fast set of data aware controls that sit
directly on top of ADO.

Tim Parker-Nance

Orion Software, Leading Edge Accounting Software