Investigando o consumo de memória do Engine

Estou investigando o consumo de memória da nova versão do Engine 4(ainda em beta), que está demasiadamente alto em algumas situações. Estou utilizando o excelente AQTime, que felizmente possui um profiler específico de uso de memória.

No Engine 4, o JavaScript Runtime realiza alguns truques para aumentar a performance, como por exemplo não chamar o destrutor de objetos que não necessitem de um clean up. Entretanto esse comportamento confunde o profiler do AQTime, passando a ser desativado no momento do profile.

Com o profiler, eu posso observar num determinado momento a quantidade de objetos de uma determinada classe. É interessante essa visão, pois permite de uma maneira mais objetiva, observar objetos que com pequenas alterações permitiriam um grande consumo de memória, tendo um impacto na performance da aplicação.

Stack Trace no Delphi

Nesta semana, trabalhei na implementação do Stack Trace no Engine Runtime. Basicamente, usei a implementação do Jcl. Infelizmente o stack trace não é muito preciso, principalmente quando ele está fazendo o trace de rotinas do interpretador JavaScript, mesmo usando a opção RawTrace, que realiza toda a operação sem confiar na existência de Stack Frames. Acredito que o FastMM utilize a mesma rotina do Jcl.

Internamente, o JclDebug faz um patch no executável em tempo de execução, alterando o System.pas para possibilitar a captura do Stack trace no momento que uma exceção é gerada. Ainda não pude observar o custo de processamente dessa operação de captura.

Além do JclDebug, existem outros projetos, como o FastCode, que requerem o uso de patchs para realizarem otimizações no Delphi. Estive pensando se não seria interessante fazer o patch, em tempo de compilação, ao invés de em tempo de execução. Acredito que fazer o patch da aplicação em tempo de execução iniba um melhor uso da memória virtual por parte do sistema operacional.