Otimizar o sistema - Deixando ele mais rapido

um processador melhor, e principalmente mais memória, se for win98 até 256, mais não adiante, troque para o xp e coloque um monte de memória

puts, vou perder um monte de cliente. pq eles usam um outro sistema meu em DOS(clipper) to querendo trocar mas agora ficou dificil. aqui o pessoal é assim (essa maquina é pra terminal não precisa de nada).
Vou dar mais uma estudada ver o que consigo fazer, se alguem tiver mais sugestões fico grato.

o sistema também precisa estar bem definido, tanto o sistema em si, quanto o banco de dados. uma modelagem bem feita melhora bastante a performance, aliado à índices bem definidos.

sem contar que o próprio sistema deve ser bem definido quanto ao modelo: client/server, n-camadas.
qualquer desses modelos têm, por definição, [b:3f7f1727d2]somente trazer registros solicitados pelo usuário[/b:3f7f1727d2], aumentando assim a performance do sistema e diminuindo drasticamente o tráfego de rede.

o fato do cliente usar outros sistemas em clipper, independentemente de quem é o autor, não tem nada a ver, vc não vai perder nada, os programas em clipper vão continuar rodando, isto é apenas para melhorar o desempenho em delphi

Eu acho que vc não entendeu a postagem que fiz anteriormente, o sistema que os meus clientes usam é meu, feito em clipper, e eu não quero mais mexer com clipper, e nem meus clientes vão querer trocar as maquinas, tipo assim eu tenho cliente que ainda usa 386, 486 esses nunca vão comprar outros computadores. E eu vou deixar de atende-los pois estou correndo do clipper. :lol: :lol: :wink:

isto do cliente jamais trocar um 286, 486 para um computador melhor é incoerente, pois já são computadores velhos e um dia vão pifar, e aí o cliente vai conseguir comprar outro 386 novo?

Senhores, senhores, senhores...

Seu cliente pode continuar com os mesmos computadores, sem qualquer problema.

Acredito que fazer a substituição de máquinas simplesmente para trocar um sistema é puramente loucura. Vejam bem, eu tenho um computador rodando Windows XP, Delphi 7 - Tem 256 mb - é um computador muito bom - vocu trocá-lo? Nunca. O que desenvolvo nele, se ficar rápido na minha máquina, ficará proporcionalmente mais rápido em outras máquinas, correto?

Existe uma regra [b:a8d0f1e6ed]besta [/b:a8d0f1e6ed]no mercado, e essa regra de mercado [b:a8d0f1e6ed]inclusive a Borland aplica e muitos vão atrás[/b:a8d0f1e6ed] - [u:a8d0f1e6ed]Troque o sistema, mas para usar o meu sistema, você tem que ter um computador da NASA - Palhaçada isso...[/u:a8d0f1e6ed]

Se você quer que os seus clientes continuem usando o seus sistema, mesmo sendo em Windows ou DOS, faça o seguinte:

Pegue uma máquina mais próxima da máquina mais ´safada´ do seu cliente.

1 - Evite usar Unit´s para implementações gráficas na Interface;
2 - Use um código bem enxuto - o mais otimizado e eficiente o possível.
3 - Se você desenvolve em Clipper, recomendo que altere a base de dados para Paradox. Veja, para que usar Interbase se o número de máquinas clientes são poucas? O Paradox é um banco de dados bem flexível e bom de trabalhar.

Dessa forma, deixando somente a base de dados no servidor, as máquinas clientes precisarão ter somente os executáveis instalados nelas - evitando usar o servidor como Shadows e havendo divisão de processamento - o que obviamente exige sempre um pouco mais de memória.

Uma outra recomendação que faria é dividir a aplicação em módulos. Dessa forma você pode na maioria das vezes diminuir o tamanho do executáveis e permitindo que esses executáveis sejam executados sem qualquer problema.

A medida que vai desenvolvendo a aplicção, instale-a na máquina mais fraca e verifique a sua performance, não faça a substituição do sistema senão você se ferra.

Se puder usar versões como Delphi 3 - será melhor ainda - por incrível que pareça.

Não concordo. Quanto mais nova a IDE, mais otimizado é o código compilado. Além de melhorias na IDE também há melhorias no compilador, o que pode tornar o código final do executável menor, mais rápido e mais eficiente.

Nildo, acho que vamos incrementar a nossa discussão;



Me dê um exemplo claro disso. Há melhorias na código ou no Compilador?
Como você consegue dizer isso? Baseado em que você diz isso? A desculpa para comprar um novo carro é dizer que o velho não vale mais nada. No setor de desenvolvimento é a mesma coisa.

Lhe pergunto então: Porque entrou um verdadeiro fracasso no mercado o Delphi 8 e que rapidamente foi substituído pelo Delphi 2005? Se muda a velocidade do processador e outros hardwares - placas de vídeo, memórias, HD e SO - será que isso não interfere automaticamente no processamento? Faça um programa com 3 forms no Delphi 3 e faça um no Delphi 2005 e veja a diferença no tamanho. Há tempos atrás, muitos críticos apontaram diretamente essa relação do inchaço dos executáveis.

Muitos partiram para o Delphi 2005 e continuam desenvolvendo a mesma coisa e com os mesmos componentes.

Lhe pergunto, quais foram as reais melhorias na IDE? Essa ´IDE MELHORADA´ beneficia quem? O desenvolvedor com uma interface mais descomplicada? O Software? Porque pelo que eu saiba, a IDE beneficia somente o desenvolvedor, concorda? Não beneficia diretamente o meu cliente - mas sim a mim.

Fico no aguardo das suas respostas com muita anciedade!

Abraços - Não me leve a mal, mas realmente gostaria de ler as suas respostas.

Eu disse isso baseado no avanço do mercado. Porém me chamou atenção sua pergunta, e como eu suspeitava eu pesquisei e achei essas informações agora pouco, e acabei me lembrando dos detalhes: http://codecentral.borland.com/Item.aspx?id=23451 . É um link de um dos palestrantes da ClubeDelphi, da TechWeek 2005 a qual eu também estava presente. Ele falou bastante sobre melhorias do compilador no Delphi 2005.



Havia realmente a necessidade do Delphi 8 na época? Mas essa pergunta já muda o rumo da discussão, mas é óbvio que Velocidade do processamento do código gerado pelo compilador ou o tamanho do executável não foram motivos para o Delphi 8 não ter ingressado devidamente no mercado.



Claro que interfere! Mas não estamos discutindo Tamanho do executável, e sim Velocidade do processamento. E o tamanho do executável não está relacionado com o clock ou com a velocidade do processamento do seu código.



O Sistema operacional muda. Os processadores mudam. Novos comandos são inclusos; comandos inúteis são excluídos; novas técnicas são encontradas para melhoria de comandos simples, complexos, todos a fim de deixar o código mais rápido. Por conta disso o compilador também tem que evoluir para atender esses novos recursos, que resulta em um código mais organizado, compatível e de maior performance.



Pense bem.. com uma interface mais ´simplificada´, com mais recursos e códigos automatizados, o seu projeto com certeza fica pronto em um tempo menor. E isso não beneficia o cliente?



Relaxa, não levo a mal. Adoro discussões!

Eu havia dito ´o que pode tornar o código final do executável menor´. PODE devido ao fato do compilador melhorar o código, mas nem sempre melhorias quer dizer redução do tamanho final do executável. Mas quanto a performance e deixar mais rápido, é fato. As vezes para se melhorar um código, é necessário mais espaço no executável. Assim como um programa feito totalmente em POO fica maior que um programa feito em rotinas e nada de POO. Ele fica bem mais organizado, facil de desenvolver, a velocidade do processamento é a mesma, porém fica maior.

Nildo, [b:f30b4d8029]achei massa as suas respostas[/b:f30b4d8029], porém cabe-me em algum pontos duvidar da exposição, vejamos:



Veja bem, se o próprio palestrante do Clube Delphi não defender o ganha pão dele, a coisa tá feia. Tudo é uma estratégia de marketing para vender o produto. Há a necessidade de se fazer isso já que o mercado não a vê com a mesma naturalidade que os ´usuários´ que simplesmente copiam e instalam em seu computadores. Com relação ao link, isso não me diz nada amigo Nildo, é a mesma coisa que perguntar para o pessoal da Ford se eles acham que o Focus ou EcoSport são bons carros. Gostaria de ver alguns nomes de pessoas reconhecidamente renomadas e as suas respectivas críticas.



Amigo Nildo, por contrário. Essa questão é uma das piores e volta justamente a ressaltar o interesse da Borland em lançar versões [b:f30b4d8029]MODISTAS[/b:f30b4d8029]. Inclusive um dos pontos mais criticados dessa versão, foi a questão da imposição ao desenvolvimento .Net. Muitos continuam programando para versões Win32 do qual foi retirado - ai surge o remendo, Delphi 2005. Isso demonstra uma estratégia barata e sem finalidade. UMA VERSÃO POR ANO. No começo a Borland não era assim.



Vejamos então, pegue um Corel Draw 5, 6, 7, 8 e 9. Veja a diferença do tamanho e veja a diferença na caixa o tópico ´Hardware Mínimo e Recomendado´. Tente rodar todos em um único computador. O tamanho do executável INTERFERE claramente no conteúdo enviado para gerenciamento de memória. Quanto menos memória, pior a coisa fica. Se com uma versão você cria um aplicativo de 500 K e em outra versão você cria um com 600 K (tudo realmente igual). Será que algo não está errado? Qual foi o motivo dessa diferença?



Quando você fala em melhorar o compilador, tudo bem. Tudo realmente ´MELHORA´. Porém não esqueça que o código compilado deve atender aos comandos básicos de processadores como pentium, pentium 2, pentium 3 e assim sucessivamente. Os mais ou menos 3000 comandos existentes nesses processadores são iguais. O compilador gerá código para esses comandos. Quais são os comandos inúteis? Mas afinal, quem você diz que muda e melhora - O Código ou o Clock?



Anteriormente você disse que eles não tinham qualquer relação lembra?



Não. O que beneficia o meu cliente é o resultado do compilador - um programa eficiente e dentro das suas expectativas. Quando você diz, ´uma interface mais ´simplificada´ ´ (até você mesmo parece não estar muito convencido da interface ´simplificada´) eu lhe pergunto: Você já parou para analisar o que usa mais da interface? Com mais palletas, supostamente exige um monitor maior ou acaba perdendo mais tempo virando abas desnecessárias. Isso não beneficia o meu cliente e tráz um
consumo maior de tempo para o desenvolvimento.

Na minha empresa, deixamos configuradas as abas com um recurso que acompanha a versão do Delphi desde a versão 1 - o arranjo de abas. Que não mudou nada desde aquela versão até a 7. A única vantagem que realmente vejo nas diferentes versões, foi o implemento do desenvolvimento compartilhado de projetos. Mas isso não beneficia a todas as pessoas que usam o Delphi como ferramenta de desenvolvimento.

Vejamos então como fica.

Abraços

Ok, Artigo do site da borland: http://bdn.borland.com/article/0,1410,32778,00.html (Vide o item 2 e 2.8)
Mas lembre-se também que um palestrante no nivel do citado não inventaria!



Concordo com você! Mas esse ponto não entra no escopo do tópico. A borland tem que correr atras dos prejuízos de um jeito ou de outro. E como toda empresa (não digo boas ou más empresas), quer ganhar dinheiro. Para isso, desculpe, mas se necessário passar por cima dos desenvolvedores eles o farão.



Sobre o comentário do Corel Draw, o que está interferindo nas exigências de máquina não é o tamanho do executável. É a versão dele, que por ser um software de edição de imagens depende diretamente de versões de DirectX, placa de vídeo boa, placas aceleradores e afins. Mas isso não vem ao caso, ou você acha realmente que o que muda da versão 5 à versão 9 é somente o tamanho do executável?

Quanto ao ao aplicativo de 500k e 600k, só porque o tamanho do executável aumenta, quer dizer que tem algo de errado? Será que o executável de 500k não teria algo errado porque ELE está menor? Ou será que um executável maior é sinonimo de código inutil dentro dele e um executável bom é um executável pequeno?



Sim, o código compilado pelo delphi 2005 deve e É compativel com o padrão dos processadores. O compilador faz melhorar o código e não o Clock. O clock está ligado somente ao processador.



No caso citado, quando disse ´um código mais rapido´ não me refiro ao clock e sim ao conjunto de códigos que vai executar uma determinada ação. Sendo maior ou menor, o resultado final, se não for mais rapido, é sempre otimizado para ser melhor. Não importando a quantidade de comandos inclusos para o processador executar.



Citei o ´simplificada´ porque você citou ´decomplicada´, e creio que a interface do Delphi não é complicada. Mais paletas para mim significa mais organização e não complicação. Quanto a virar abas desnecessárias, eu costumo deixar as abas mais usadas como sendo as primeiras abas. Mas com uma IDE mais organizada eu perco menos tempo achando o que eu quero e tendo acesso as funções. Logo eu consigo finalizar o programa em um tempo relativamente bom. O que trás satisfação ao cliente, e pode ter certeza que os clientes preferem uma empresa que fazem as coisas mais rapidas e melhores do que uma empresa que demora para fazer as tarefas. Mas não vamos discutir esse ponto, até mesmo porque o tempo perdido em uma IDE desorganizada (não que as versões antigas sejam) é mínimo.



Mas com certeza outros recursos beneficiam outros tipos de pessoas. A borland não vai pensar só em você, vai pensar em todos os desenvolvedores e o que todos eles necessitam.

Abraços!

Esse tópico é interessante, tendo em vista o alto nível dos participantes com excessão de minha pessoa é claro.

Essa questão de tamanho de executável maior, menor, parece muito com questões levantadas entre o tamanho de uma aplicação gerada pelo C++ e outra pelo Delphi. Acredito q o tamanho do executável vai dos recursos q este visa ter, nas mudanças de versões do Delphi, muita coisa foi implementada na VCL e muita coisa foi otmizada tb. Tudo visa melhorar, claro q alguns ainda usam as versões 3, 5, 6, 7, 2005 e alguns já estão iniciando na 2006, o Anderson (Afarias) e acredito q o Massuda ainda rodam o Delphi 5 com seus Updates claro, essa questão de requesitos de Hardware e talz visa tornar o processo de desenvolvimento mais rápido, pq uma máquina lerda o programador vai passar um bom tempo compilando um sistem de médio porte.

Uso o Delphi desde a versão 3, e já rodei Delphi 7 em um AMD K-6II na boa, assim como já rodei o mesmo em um Pentium - IV.

Espero q continuem com esse tópico tão interessante.


Abraços!!!

Respondendo ao autor do tópico: esse seu sistema é em rede? Se sim, esse AMD K-6 II é a melhor máquina? Se não for, coloque o server do Firebird na melhor máquina disponível na rede pq o Firebird consegue rodar em máquinas mais fracas (já rodei até em Pentium 100 com 32MB de memória), mas num ambiente de rede ele teria mais trabalho, desde que a aplicação tenha sido planejada. E como os demais colegas sugeriram, analise seu aplicativo e a base e veja se é possível otimizá-los.

posso garantir que um k6II e sufuciente para processar informações com uma base tipo interbase, pois aqui na empresa processamos +/- 300.000 clientes nas recepcoes e temos ate P MMX 233 com 64 MB ram e que faz o serviçi direitinho...

Aí galera, o papo tá bom, mas e pra resolver o problema do amigo ??? :?:

Uma regra básica é deixar na memória apenas o que se está usando. Se seu programa tem 100 formulários e você deixa os 100 no autocreate do Delphi você está ocupando memória desnecessáriamente. Por exemplo uma tela de configuração. A tela de configuração só deve ser criada quando o cliente chamar esta tela, pois raramente ele acessa a tela de configuração.
Não sei como é no Interbase, mas em Oracle as consultas SQLs tinham de ser bem pensadas pois conforme fosse a ordem dos campos na cláusula Where (campos menos significativos e textos primeiro) o SQL podia durar 1 segundo ou 1 minuto, dependendo do tamanho do SQL.
Sugiro ao amigo verificar qual a funcionalidade que está lenta. Normalmente é consulta a banco que trava o sistema. Se puder, rode o sistema com Delphi na máquina lenta e, pelo debug, veja onde o sistema está ficando lento. Caso não possa instalar o Delphi, use ShowMessage para saber quanto tempo determidados procedimentos estão demorando.
Boa sorte...