Diminuindo o tamanho do Executável do VFP

[Marcos Guedes]

Autor: Fabiano Costa
Fonte:

Parte 1: imasters.uol.com.br/artigo/7690
Parte 2: imasters.uol.com.br/artigo/7912

Até pouco tempo atrás o que preocupava um programador era a quantidade de memória que ele usava. Tínhamos pouca memória para executar nossos programas, então bibliotecas e overlay dinâmicas era a nossa salvação e recorríamos a elas para que as máquinas não sucumbissem aos nossos sistemas que só faziam crescer.

Embora a quantidade de memória ainda seja um fator que deva ser levado em consideração, atualmente o grande problema do desenvolver é o tamanho do seu sistema, pois com tudo acontecendo na internet o grande inimigo hoje é a largura de banda principalmente porque atualizações não ocorrem mais por CDs ou disquetes, mas por HTTP, FTP e e-mail.

O que era um pequeno programa de cadastro de clientes com 400k com o passar do tempo tornou-se um belo sistema de relacionamento com o cliente, os códigos foram sendo criados, as classes expandidas, as imagens e ícones agora estão cada vez mais presentes e elaboradas e num piscar de olhos pronto: Seu executável já esta com 8Mb. Mandar isso para um cliente pode ser um tormento em links pequenos e muitas vezes linhas discadas fazem do que era uma comodidade um tormento.

O VFP tem pequenos truques para diminuir o tamanho dos executáveis, neste artigo vou mostrar dois deles, para isso criei um pequeno projeto que usa a tabela "Product.dbf" que vem com o VFP e executei o wizard para que ele montasse minha tela rapidamente como abaixo:

[Você precisa estar registrado e conectado para ver esta imagem.]

Agora no meu projeto eu tenho as classes do wizard, os desenhos do botão e meu Form propriamente dito. Ao compilar esse projeto terei um executável de 248k. Parece que não é muito, mas se pensarmos que é apenas um Form imagine uma aplicação com oitenta, noventa Forms com muito código embutido.
A primeira coisa que pode ser feito para diminuí-lo é retirar do executável as referências do Debug que por padrão vem marcado para serem inclusas. Estas informações são interessantes para quando está testando o programa em ambiente controlado, mais totalmente desnecessárias em ambiente de produção. Para encontrar essa opção acesse o menu Project e escolha Project Info como na figura abaixo:

[Você precisa estar registrado e conectado para ver esta imagem.]

Aparecerá uma tela como esta abaixo:

[Você precisa estar registrado e conectado para ver esta imagem.]

Desmarquei o debug e compilei novamente o programa. O mesmo programa está agora com 172k, ou seja, nosso executável com um pequeno ajuste ficou 30% menor, sem alterar uma linha do fonte sequer.
Na segunda parte dessa matéria irei mostrar como diminuir ainda mais o executável com mais alguns pequenos ajustes.

Como visto na primeira parte desse artigo, fazer o ajuste do Debug é simples e funcional. Mas pode-se diminuir ainda mais o tamanho quando fazemos o VFP trabalhar de forma mais funcional:

APP
Uma app é um processo pré-compilado que entre outras funcionalidades pode ser usado como biblioteca de classe do VFP permitindo assim que rotinas que normalmente não sofre quase nenhuma manutenção possam ser colocadas nestas apps e assim diminuir consideravelmente os tamanhos dos executáveis.
Para acessar uma classe, normalmente damos o comando "set classlib to <minhaclasse> additive". O que podemos fazer agora é dar o mesmo comando, mas referenciando-se a APP: "set classlib to <minhaclasse> additive in classes.app". O VFP vai tentar abrir o arquivo classes.app e trazer para a memória a classe solicitada.

Assim teremos dois arquivos distintos: Um com as classes que praticamente não sofrem alterações e outro com os processos peculiares do sistema propriamente dito.
Se fizermos este procedimento no exemplo da primeira parte deste artigo, o executável agora passará a ter 60k, ou seja, 112k eram apenas das classes que praticamente nunca vou modificar, mas que a cada nova compilação mando integralmente para o cliente, consumindo tempo, banda e dependendo da conexão, muita paciência.

Existem alguns casos em que se pode separa as classes em diversas APPs, para cuidar da ECF, para a manutenção do banco e as classes de negócios entre outras, permitindo assim que ao alterar o comportamento de alguma a atualização da base instalada seja simples e rápida.

Desenhos:
Outra coisa que realmente consome um tamanho enorme dos executáveis são as imagens BMPs, JPGs, etc, que normalmente colocamos em nossos sistemas. O melhor caminho possível e deixar no executável apenas o indispensável. O restante crie um diretório na sua aplicação com o nome, por exemplo, de "imagens" e coloque este caminho da no "SET PATH" no inicio da aplicação. Lembre-se, se alguém gostar da imagem que você tem, ela pode dar um "print screen" e capturá-la. Guardá-la no executável para protegê-la não adianta em nada.
Para excluir as figuras do seu executável, basta dar um clique com o botão direito do mouse e escolher a opção exclude conforme figura abaixo:

Retiramos os 12 arquivos de imagens do executável e se formos comparar verá que o mesmo agora tem 57k, o que reduz mais ainda o arquivo e deixando o executável apenas com o que realmente interessa: O código que pode sofrer manutenção constante.

Agora, quando eu tiver que enviar uma alteração no meu sistema, não mandarei mais para o cliente um arquivo de 248k, mas sim um arquivo de 57k, uma redução de 77% no meu fonte ganhando muito mais comodidade e tempo e banda da internet para executar outros processos que não atualizar os dados dos clientes.
Veja qual o tamanho do seu executável hoje e, utilizando estas dicas, qual o tamanho que ele vai estar e avalie se o ganho compensa fazer estas modificações.

Obs: Para sugestões e esclarecimento de dúvidas, visitem a página oficial!

[marcio]

Olá amigos!

Nossa, muito boa essa dica. Só com a primeira (Debug info) eliminei 18Mb do .exe do sistema, que estava com 54Mb e caiu pra 36Mb.

Valeu pela dica.

Abraços

[hugo]

muito bom isto ai

[mfelis]

Muito Bom.