A verdade sobre o TDataModule e o consumo de memória
Escrito por Carlos B. Feitoza Filho | |
Categoria: Artigos | |
Categoria Pai: Addicted 2 Delphi! | |
Acessos: 8311 |
Muito se fala e pouco se aprofunda, por isso tomei as dores do pobre TDataModule e, a fim de provar sua inocência, comecei verificando sua hierarquia, e notei que o TDataModule tem menos "pais" do que o TForm. Estou usando o TForm como exemplo porque, primariamente e da forma mais básica possível, um TDataModule é um contêiner de componentes não visuais e um TForm também aceita componentes não visuais e por isso um programa pode muito bem ser criado sem que haja sequer um TDataModule, contudo, TDataModules ajudam a modularizar um programa e, usando-o da forma mais básica, é possível manter as coisas organizadas, concentrando seus componentes não visuais em um TDataModule e evitando que um tela complexa (e com muitos componentes não visuais) fique poluída. A quantidade de hierarquias é sim um fator crucial para a contabilização do consumo de memória, e se um TDataModule tem menos hierarquias do que um TForm, as chances dele consumir menos memória do que este último é bem elevada. Achei isso muito curioso e fui investigar mais a fundo
Algumas pessoas vão dizer que tudo pode ser criado dinamicamente e não é preciso ter quaisquer componentes não visuais em designtime, seja em forms, seja em data modules, mas entenda que o intuito desse artigo é mostrar a verdade sobre o TDataModule ser ou não um consumidor de memória. Além disso, iniciantes não vão jamais criar componentes em tempo de execução. É muito mais fácil soltar um TQuery num TForm (ou TDataModule) do que lidar com construtores, destrutores e atribuição programática de propriedades. Este texto é destinado aos iniciantes, para que eles não acreditem em tudo que lêem e usem os componentes da melhor forma possível, até que um dia resolvam "complicar", criando tudo em runtime, que trás poucas vantagens, diga-se. Minha opinião é de que se eu posso fazer as coisas de forma visual, eu vou fazer de forma visual porque isso facilita minha vida. Não existe um concurso secreto que dá prêmios em dinheiro pra programadores que fazem tudo de forma linda, OO ou sem gambiarras! Aliás, aquele que nunca fez uma gambiarra que atire o primeiro teclado :)
Sim, mas e o tamanho do TDataModule?
Colocar um TDataModule numa aplicação aumenta seu consumo de memória? Claro que aumenta! Tudo que é incluído numa aplicação, seja em designtime, seja em runtime, impacta no consumo final de memória. O que quero comprovar aqui é que, colocar um TDataModule em uma aplicação não é diferente de incluir um TForm, por exemplo. O consumo de memória de um TForm e de um TDataModule é similiar, o que significa que uma aplicação com um TForm e um TDataModule é maior do que uma aplicação com apenas um TForm, mas usar um TDataModule para organizar o código e concentrar componentes não visuais COMPENSA este leve aumento.
Como foi que cheguei a esta conclusão a respeito do tamanho do TDataModule? Simples! Criei um projeto (que está anexado a esta publicação) que faz medições de consumo de memória antes e após a criação/destruição de diversos objetos. Baixe o projeto e execute-o. Ele é guiado passo-a-passo. Tire suas próprias conclusões
E daí?
E daí que, da próxima vez que alguém disser que a culpa é do TDataModule, você poderá dar o link deste artigo e esperar que a pessoa não seja muito cabeça dura pra entender de uma vez por todas que, normalmente, a culpa do consumo de memória desenfreado é de componentes de terceiros ou programação inadequada. Obrigado por ler :)