A minha modificação referente ao meu post anterior sobre melhoria de performance no DataSnap, mais especificamente quando está obtendo dados de um DataSet ADO (dbGo), é chamar o DisableControls do DataSet ANTES de obter os dados.
Porquê isto tem significativo impacto na performance do ADO? A resposta está na unit ADODB.pas mais especificamente no método InternalGetRecord, como mostrado abaixo:
if (BookmarkSize > 0) and ((adRecDeleted and RecordStatus) = 0) then
begin
BookmarkFlag := bfCurrent;
Bookmark := Recordset.Bookmark;
if ControlsDisabled then
RecordNumber := -2 else
RecordNumber := Recordset.AbsolutePosition;
end else
BookmarkFlag := bfNA;
Note que no interior do método, um trecho do código que SEMPRE é executado contém "if ControlsDisabled". Quando ControlsDisabled retorna FALSE, é chamado o método AbsolutePosition do Recordset que é lentoooooooo, muito lento!
Durante o processo de prover os registros do ADODataSet não é necessário saber a posição absoluta no RecordSet, portanto não há necessidade nenhuma disso!
Teríamos duas soluções: Editar o ADODB.pas uma vez que o método InternalGetRecord não é virtual ou dinâmico (não cabendo então override), ou chamar DisableControls na mão, antes de abrir o ADODataSet a partir do DataSet provider.
Preferi não mexer no ADODB.pas (por enquanto!), e sim criar um descendente do DataSetProvider, chamado por mim de TDataSetProviderEx, que chamasse explicitamente o DisableControls ANTES de prover os registros.
Um porém é: Não se pode chamar DisableControls em um DataSet master que participa de uma relação Master-Detail, pois o detalhe não ficaria sincronizado com o master. Então, como fazer? Bem, a minha solução basicamente está em fazer um novo método InternalGetRecords do DataSetProviderEx, como abaixo:
function TDataSetProviderEx.InternalGetRecords(Count: Integer; out RecsOut: Integer;
Options: TGetRecordOptions; const CommandText: WideString;
var Params: OleVariant): OleVariant;
var
CanDisableControls: boolean;
begin
CanDisableControls := DSCanDisableControls;
if CanDisableControls then
DataSet.DisableControls;
try
Result := inherited InternalGetRecords(Count, RecsOut, Options, CommandText, Params);
finally
if CanDisableControls then
DataSet.EnableControls;
end;
end;
onde DSCanDisableControls é o método:
function TDataSetProviderEx.DSCanDisableControls: boolean;
begin
Result := SmartDisableControls and not IsMaster;
end;
SmartDisableControls é uma propriedade que incorporei à classe TDataSetProviderEx e indica se é desejável tentar chamar DisableControls antes de prover os registros ou não. Esta propriedade é TRUE por default pois não vejo motivo para não chamar DisableControls antes. O método IsMaster verifica se existem detalhes do DataSet, ou seja, se o DataSet participa como MASTER numa relação Master/Detail:
function TDataSetProviderEx.IsMaster: boolean;
var
List: TList;
begin
Result := False;
if Assigned(DataSet) then
begin
List := TList.Create;
try
DataSet.GetDetailDataSets(List);
Result := List.Count > 0;
finally
List.Free;
end;
end;
end;
Caso o DataSet não seja Master e caso a propriedade SmartDisableControls for TRUE, então DisableControls será chamado antes de se prover os registros. O ganho de performance é ENORME em DataSets ADO. Em alguns casos que eu testei chegou a 500% de ganho (DataSets com 30.000 registros ou um pouco mais). O ganho é tão mais perceptível quanto maior for o DataSet ADO que proverá os registros.
A minha classe TDataSetProviderEx já está em vários sistemas em produção, entre eles Windows Services rodando 24x7, há pelo menos 6 meses, ou seja, funciona! E o ganho de performance é considerável! Lembrando: O ganho de performance ocorre para DataSets que usam ADO (dbGo) do Delphi. DBExpress e outros mecanismos de acesso à dados não possuem este "defeito de nascença" e portanto não serão afetados em sua performance.
Agora só falta acabar de empacotar o código do DataSetProviderEx e fazer o seu upload! :-)
