a.Himem – d.Himem, PHP+MySQL – POO+MVC
Antes e Depois do Himem e a Glutonaria do PHP Orientado a Objetos usando MVC
Um dia mostrei um programa para dois amigos também programadores, e eles ficaram chocados. Comentaram entre si como meu programa executava rápido e me perguntaram em que linguagem eu havia feito. Quando falei que fiz em PHP ficaram ainda mais chocados, pois ambos utilizam esta linguagem diariamente, e não conseguiam compreender como meu sistema executava mais rápido que o deles.
Gostaria de fazer uma viagem no tempo para contextualizar minhas opiniões sobre sistemas e a velocidade em que eles são executados, com ênfase final ao famoso LAMP, ou seja, PHP com banco de dados MySQL ou MariaDB, rodando em servidor Apache em sistema operacional Linux.
Comecei a programar computadores no final da década de 1980, naquela época os computadores usados em pequenas empresas do interior eram máquinas muito limitadas, principalmente se comparadas com os padrões atuais, de forma que esta comparação é injusta e não será feita. Em geral, utilizavam disquetes para executar o sistema operacional e armazenar dados, não tinham um disco rígido, e dispunham somente de 64K de memória, nada mais. O primeiro programa que fiz foi num computador CP-500 da Prológica, usava três disquetes de densidade simples para o programa, lido em unidade primária, e um disquete para armazenar os dados na unidade secundária. Todo cuidado devia ser tomado para que se conseguisse usar um programa, visto que o espaço de armazenamento era pequeno e a memória a ser utilizada também era extremamente limitada.
A pequena cidade onde vivia e vivo, a evolução foi lenta, até que se chegou ao famoso PC-XT. Fantástica máquina, com mais memória – inicialmente 128 kB mas rapidamente evoluiu para 512 kB, e mais rapidamente ainda evoluiu para 640 kB, um sistema operacional mais fácil de entender que o CPM (que nem é considerado sistema operacional e apesar do XT ainda vir com o BASICA na ROM). O sistema operacional DOS, mais lógico que o BASIC rodando na BIOS dos computadores RadioShack e Prologica e que o próprio BASICA a ROM do XT, era mais rápido que tudo o que se via em ambientes computacionais locais, um grande avanço.
Mas este avanço também tinha suas limitações, o sistema operacional ocupava grande parte da memória, um pedaço ficava reservado, e sobrava pouco. Ainda assim, neste pouco, programas fantásticos foram feitos em várias linguagens.
O DBase II, logo o III era o carro chefe em banco de dados, o Clipper Summer87 compilava os mais diversos programas, era o que mais se via! Ainda sobrava espaço para Cobol, Pascal, e diversas outras linguagens. Poucos se aventuravam a usar Linguagem C porque outras linguagens aceleravam o tempo de desenvolvimento.
Eu preferi o Clipper, rápido, linguagem simples, prático, estável e muito versátil – pirateava fácil, mas deixa isso para lá – e muitas soluções foram criadas com ele. Como o espaço de memória era limitado, tínhamos que ter cuidado extremo com o tamanho e a forma do programa que fazíamos, principalmente porque as versões subsequentes do Clipper carregavam muitas bibliotecas na RAM, e se os bancos de dados ficassem muito grandes, corríamos o risco de ter uma mensagem “Stack overflow”, e o programa cair de forma não muito graciosa!! Se isso acontecesse, podia corromper os índices do banco de dados, e gerar outros transtornos.
Muitos de nós, aprendemos a usar Overlays, onde um núcleo do nosso programa ficava na memória, e uma parte era chamada somente quando fosse necessária. Diminuia o overhead, mas também exigia certos cuidados. Se um overlay fosse chamado enquanto outro ainda estivesse ativo, o sistema travava. Tinha que resetar o PC para se livrar da situação. Desta forma, nossa tarefa não era só programar. Tínhamos que gerenciar o espaço de memória para nosso programa, para o banco de dados. Tínhamos que ter uma politica de transferência de dados para que a tabela operacional do banco de dados não ficasse muito lenta, e cuidar para não receber o famigerado “Stack overflow”! O sonho diário era aprender definitivamente a vencer o pesadelo – ou seja, era pesadelo.
Finalmente, lançaram computadores com mais memória, agora subiu de ordem, dos Kilos para os Megas! Fantástico, 1024 kB de RAM, ou como a gente gostava de dizer, 1 Mega de memória, era o sonho de consumo de todo mundo! Muitos compravam máquinas com 1 Mega de memória, mas o MS-DOS (que se tornou popular entre os PC’s – nem vou me meter nesse assunto), só enxergava 640 kB. O problema não se resolvia simplesmente adicionando mais memória. Era necessário fazer com que o MS-DOS enxergasse e conseguisse usar a memória adicional.
DEVICE=C:\DOS\HIMEM.SYS
Nasce o Himem.sys (High Memory) que permitia o acesso à parte alta da memória, considerada acima dos 640 kB.
Uma maravilha, e um entrave, porque muitos programadores começaram a ignorar o gerenciamento de memória e dados que antes executavam, se esquecendo de que seus clientes nem sempre tinham esta memória adicional. Faziam programas em seus computadores devidamente configurados, com mais memória, e quando instalavam nos computadores de seus clientes, logo recebiam a mensagem de boas vindas à realidade: Stack overflow!! Hilário para alguns, decepcionante para outros.
A partir daí a quantidade de memória foi aumentando, e o desleixo e falta de cuidado de muitos programadores também. Depois vieram sistemas operacionais com melhor gerenciamento de memória, programação preemptiva, melhor escalonamento de processo e o desleixo foi aumentando. Muitos ignoravam que os programas criados faziam o sistema operacional ter que gravar dados no HD para liberar memória para executar suas rotinas, e que o SWAP (troca de contexto entre RAM e HD) é um dos processos mais custosos, e simplesmente culpavam o sistema operacional ou a máquina pela lentidão. Para superar isso, processadores mais rápidos, mais memória, e quanto mais isso, mais desleixo e falta de cuidado com o programa e como ele utiliza estes recursos.
Hoje, duvido que a maioria dos programadores que desenvolvem sistemas comerciais se preocupam com memória ou com processamento. Está lento, aumenta a memória, continua lento, troca o computador. Virou um mundo estranho de relegar o desleixo.
Sim, agora voltemos ao LAMP+POO+MVC. Sou fã de tudo isso, mas com reservas. Minha linguagem de programação preferida é Java – apesar de não usar muito. Adoro PHP, mesmo tendo preferencia por Java, mas acredito que o PHP não esteja pronto para ser programado com orientação a objetos, não de forma simplória justificando que é uma linguagem interpretada, porque o Java também o é, mas o Java tem uma pré-compilação que o coloca em vantagem quanto a POO, enquanto, tudo o que vi de PHP orientado a objetos, tem um código que é interpretado e este é usado para ler as classes e rotinas antes de interpretar novamente, ou seja, o núcleo do PHP interpreta o interpretador do código orientado a objetos. Vi muitas coisas, mas não vi nada diferente ainda. Desta forma, uso pouco POO em PHP, só uso quando as classes podem ser usadas de maneira completamente autônomas, no mais, uso programação estruturada ou procedural. Simples assim. Sacrifico um pouco a modernização da forma de programar, mas ganho em desempenho. Isso não requer que o MVC seja sacrificado, e o uso de classes em Javascript e CSS adicionam uma carga no lado do cliente, mas não tem como fugir muito disso. O importante é que o núcleo do sistema responda rápido, e para isso é usada a combinação de uso eficiente da capacidade de processamento do servidor aliado ao menor uso de memória possível, ganhando em desempenho.
Quando um de meus amigos, citados no começo deste texto me questionou se eu sabia programar usando orientação a objetos em PHP, justifiquei que até o Kernel do Linux é feito em programação estruturada, ou pelo menos era na ocasião, este é meu segredinho!!
Bom LAMP+POO+MVC para todos!!
Free-lancer em desenvolvimento, treinamento e rede de computadores.1 article
