[OFF] ECONOMIA DE RECURSOS...
Olá a todos, estive conversando com o Professor Mário Andrade
(aproveito para agradecer pela grande atenção) e ele me passou
dicas sobre economia de recursos em VB6.
Ao estudar C# percebi que isso é uma preocupação geral nos dias
de hoje. O que me deixa inquieto é que os computadores estão cada
vez mais evoluÃdos, praticamente nem se encontra mais memória de
512GB nas lojas, ou seja, é um pouco [Ô]desnecessário[Ô] tanta preocupação
em economizar recursos visto que existem computadores domésticos com
32GB de memória e sem falar nos HD's SSD's que turbinam tudo...
Em resumo, será que essa [Ô]economia[Ô] de recursos vale para qualquer tipo
de software ou é apenas uma prevenção no sentido de educar o programador
para se algum dia for criar algo grande?
Será que ao criarmos um sistema pequeno que tenha no máximo 5 ou 10 mil
registros precisamos nos preocupar com essa [Ô]economia[Ô]?
Deixem suas opiniões, ponto de vista, experiências etc...
Todo comentário é bem vindo....
(aproveito para agradecer pela grande atenção) e ele me passou
dicas sobre economia de recursos em VB6.
Ao estudar C# percebi que isso é uma preocupação geral nos dias
de hoje. O que me deixa inquieto é que os computadores estão cada
vez mais evoluÃdos, praticamente nem se encontra mais memória de
512GB nas lojas, ou seja, é um pouco [Ô]desnecessário[Ô] tanta preocupação
em economizar recursos visto que existem computadores domésticos com
32GB de memória e sem falar nos HD's SSD's que turbinam tudo...
Em resumo, será que essa [Ô]economia[Ô] de recursos vale para qualquer tipo
de software ou é apenas uma prevenção no sentido de educar o programador
para se algum dia for criar algo grande?
Será que ao criarmos um sistema pequeno que tenha no máximo 5 ou 10 mil
registros precisamos nos preocupar com essa [Ô]economia[Ô]?
Deixem suas opiniões, ponto de vista, experiências etc...
Todo comentário é bem vindo....
Na minha opinião, devemos desenvolver softwares para máquinas a partir de configurações bem modestas, pq nem todas as máquinas possuem configurações top.
Na empresa onde trabalho, os computadores são Dell e a configuração padrão é processador i5, 4Gb de memória e HD convencional.
Na empresa onde trabalho, os computadores são Dell e a configuração padrão é processador i5, 4Gb de memória e HD convencional.
E acho tbm que o nosso sistema não irá rodar sozinho na máquina , sempre haverá outros softwares disputando recursos com os nossos softwares. Fora que softwares que devoram recursos não são bem vistos. A gente não reclama que o Firefox consome muita memória?
Não há nada de errado em [Ô]economizar[Ô] recursos, todavia
essa economia fazia realmente mais sentido ou digamos que era
realmente indispensável no tempo em que o VB6 foi lançado.
O fato é que muito dessa [Ô]economia[Ô] pode também ser interpretada
como boas práticas de programação.
essa economia fazia realmente mais sentido ou digamos que era
realmente indispensável no tempo em que o VB6 foi lançado.
Citação:...será que essa [Ô]economia[Ô] de recursos vale para qualquer tipo
de software ou é apenas uma prevenção no sentido de educar o programador
para se algum dia for criar algo grande?
O fato é que muito dessa [Ô]economia[Ô] pode também ser interpretada
como boas práticas de programação.
Citação::
E acho tbm que o nosso sistema não irá rodar sozinho na máquina , sempre haverá outros softwares disputando recursos com os nossos softwares. Fora que softwares que devoram recursos não são bem vistos. A gente não reclama que o Firefox consome muita memória?
Muito bem observado Marcos, eu mesmo não uso o firefox por conta disso.
por isso uso maquina virtual não tao forte, e maquinas fÃsicas já bem antigas pra ver como tudo se comporta...
meu desktop mesmo de desenvolvimento é um i5 de primeira geração, tem 14Gb de memoria, e SSD, é uma maquina pro meu uso não deixa nada a desejar.....então já não é uma maquina top, dentro dela ainda rodo maquina virtual, de sobras eu tenho maquinas fÃsicas tmb.....
meu desktop mesmo de desenvolvimento é um i5 de primeira geração, tem 14Gb de memoria, e SSD, é uma maquina pro meu uso não deixa nada a desejar.....então já não é uma maquina top, dentro dela ainda rodo maquina virtual, de sobras eu tenho maquinas fÃsicas tmb.....
Citação::
por isso uso maquina virtual não tao forte, e maquinas fÃsicas já bem antigas pra ver como tudo se comporta...
meu desktop mesmo de desenvolvimento é um i5 de primeira geração, tem 14Gb de memoria, e SSD, é uma maquina pro meu uso não deixa nada a desejar.....então já não é uma maquina top, dentro dela ainda rodo maquina virtual, de sobras eu tenho maquinas fÃsicas tmb.....
Conheci as máquinas virtuais com os cursos do professor Mário Andrade
e nunca mais deixei de usar...
Bem, vamos à mais uma das tradicionais explicações longas do KERPLUNK!
Recursos são sempre limitados. Isso é fato, seja num desktop, num tablet ou celular, ou mesmo em um super computador top de linha como o Jaguar. Outro fato relevante aqui é a visão que a maioria está tendo, focado em aplicações desktop, mas vamos chegar lá, calma. Vamos analisar o caso de um desktop que é o que a maioria aqui está familiarizado. Digamos que ele seja um i5, 4Gb de ram e um HD de uns 500Gb. Uma máquina não top, mas longe de ser ruim. Para uma máquina dessas, as aplicações desktop mais pesadas teriam que lidar com cubos de dados locais, com cache enorme e uso extensivo de memória para o usuário sentir alguma lentidão. Mas veja que essa não é a realidade da maioria, que é de usarem máquinas muito inferiores à isso. Então aplicações desktop devem sim ser desenvolvidas tendo otimização de recursos em mente. Queries muito grandes, telas muito cheias de imagens ou controles com uso do GDI+, e mais uma série de outros fatores podem influenciar negativamente no funcionamento. Mas a otimização de recursos se torna realmente essencial com as aplicações centralizadas, geralmente Web, como WebAPI[ô]s e aplicações Web. Pense em um Facebook, por exemplo. Imagine quantos usuários estão nesse exato momento fazendo dezenas de requisições por conteúdo, postando vÃdeos e fotos, adicionando amigos, jogando e muitas outras atividades. Tudo isso será processado no servidor em algum momento, que precisará fazer a sincronização para organizar a linha do tempo e esta seja exibida de forma correta. Pense também em um serviço como o da NFe, que recebe dezenas de milhares de chamadas por segundo em momentos de pico(ainda mais porque SOAP é uma tecnologia ultrapassada e difÃcil de se otimizar). Notas sendo enviadas, consultadas e todas as outras operações. Nesses casos, sem uma otimização do uso de recursos, o resultado seria uma catástrofe em termos operacionais. Entendam que aplicações desktop, mesmo ainda tendo muito mercado e não estarem nem perto de serem aposentadas, não é a preferência de empresários com visão de futuro. Aplicações Web(WebAPI), queira ou não, são a tendência do mercado. Integrando desktop, dispositivos móveis e até mesmo IoT(Internet of Things). Em conclusão, aplicações desktop não necessariamente tenham que ter um controle rigoroso do uso de recursos, apesar de ser uma excelente idéia, mas para aplicações centralizadas, isso é indispensável.
Recursos são sempre limitados. Isso é fato, seja num desktop, num tablet ou celular, ou mesmo em um super computador top de linha como o Jaguar. Outro fato relevante aqui é a visão que a maioria está tendo, focado em aplicações desktop, mas vamos chegar lá, calma. Vamos analisar o caso de um desktop que é o que a maioria aqui está familiarizado. Digamos que ele seja um i5, 4Gb de ram e um HD de uns 500Gb. Uma máquina não top, mas longe de ser ruim. Para uma máquina dessas, as aplicações desktop mais pesadas teriam que lidar com cubos de dados locais, com cache enorme e uso extensivo de memória para o usuário sentir alguma lentidão. Mas veja que essa não é a realidade da maioria, que é de usarem máquinas muito inferiores à isso. Então aplicações desktop devem sim ser desenvolvidas tendo otimização de recursos em mente. Queries muito grandes, telas muito cheias de imagens ou controles com uso do GDI+, e mais uma série de outros fatores podem influenciar negativamente no funcionamento. Mas a otimização de recursos se torna realmente essencial com as aplicações centralizadas, geralmente Web, como WebAPI[ô]s e aplicações Web. Pense em um Facebook, por exemplo. Imagine quantos usuários estão nesse exato momento fazendo dezenas de requisições por conteúdo, postando vÃdeos e fotos, adicionando amigos, jogando e muitas outras atividades. Tudo isso será processado no servidor em algum momento, que precisará fazer a sincronização para organizar a linha do tempo e esta seja exibida de forma correta. Pense também em um serviço como o da NFe, que recebe dezenas de milhares de chamadas por segundo em momentos de pico(ainda mais porque SOAP é uma tecnologia ultrapassada e difÃcil de se otimizar). Notas sendo enviadas, consultadas e todas as outras operações. Nesses casos, sem uma otimização do uso de recursos, o resultado seria uma catástrofe em termos operacionais. Entendam que aplicações desktop, mesmo ainda tendo muito mercado e não estarem nem perto de serem aposentadas, não é a preferência de empresários com visão de futuro. Aplicações Web(WebAPI), queira ou não, são a tendência do mercado. Integrando desktop, dispositivos móveis e até mesmo IoT(Internet of Things). Em conclusão, aplicações desktop não necessariamente tenham que ter um controle rigoroso do uso de recursos, apesar de ser uma excelente idéia, mas para aplicações centralizadas, isso é indispensável.
No caso de programas para Desktop, acho que, para o que a maioria das pessoas aqui faz, o máximo que você precisa se preocupar se tratando de .Net é com recursos não gerenciados (unmanaged) e o uso de grandes quantidades de dados.
Se tratando de recursos não gerenciados os mais comuns são acesso a banco de dados e o uso do GDI+, que se dá através do namespace System.Drawing.
Os erros mais comuns em ambos os casos é de não chamar o Dispose, e é muito comum eu ver isso principalmente com o GDI+, pois vejo que muita gente não sabe o quando se deve chamar o Dispose principalmente em objetos do tipo Font, Brush, Pen e Image, ou qualquer uma de suas subclasses, aliás deve ter muita gente que nem sabe que precisa chamar o Dispose para esses objetos. é muito comum ver pessoas usando códigos para exibir uma imagem em um PictureBox e ao trocar a imagem não se preocupa em dar Dispose na imagem anterior se não vai mais usá-la.
E quanto a grande quantidades de dados também é comum ver pessoas reclamando que o programa ficou lento e você vai ver ele está tentando carregar 5 milhões de registros em um Grid.
Agora existem casos em que se tem que ter mais cuidado com o uso de recursos, o mais comum aqui seria o de desenvolvimento Mobile, por exemplo com o Xamarin, pois o Android limita bastante o quanto de memória seu aplicativo pode usar, para não acontecer de um único aplicativo usar todos os recursos do sistema, é bem fácil dar erro no programa se você ficar carregando imagens sem liberar a memória quando não tiver usando mais elas.
E um caso especÃfico em que se tem que tomar muito cuidado com o uso de recursos é o desenvolvimento de jogos, pois neste caso você precisa se preocupar com o Garbage Collector, ou melhor dizendo, precisa evitar que ele seja chamado com frequência, e para isso você precisa é evitar alocações, e um dos grandes vilões neste caso é o uso de strings, pois o que geralmente não faz diferença para um programa normal faz muita diferença para um algoritmo que deveria ser executado 60 vezes por segundo, pois o simples fato de concatenar strings já gera uma nova alocação afinal strings são imutáveis, o que pode gerar centenas de objetos por segundo que vão precisar ser liberados pelo GC, o que em um momento qualquer pode gerar uma pequena pausa em seu programa, o que não seria percebido se não fosse o caso dele precisar rodar tão rápido
Se tratando de recursos não gerenciados os mais comuns são acesso a banco de dados e o uso do GDI+, que se dá através do namespace System.Drawing.
Os erros mais comuns em ambos os casos é de não chamar o Dispose, e é muito comum eu ver isso principalmente com o GDI+, pois vejo que muita gente não sabe o quando se deve chamar o Dispose principalmente em objetos do tipo Font, Brush, Pen e Image, ou qualquer uma de suas subclasses, aliás deve ter muita gente que nem sabe que precisa chamar o Dispose para esses objetos. é muito comum ver pessoas usando códigos para exibir uma imagem em um PictureBox e ao trocar a imagem não se preocupa em dar Dispose na imagem anterior se não vai mais usá-la.
E quanto a grande quantidades de dados também é comum ver pessoas reclamando que o programa ficou lento e você vai ver ele está tentando carregar 5 milhões de registros em um Grid.
Agora existem casos em que se tem que ter mais cuidado com o uso de recursos, o mais comum aqui seria o de desenvolvimento Mobile, por exemplo com o Xamarin, pois o Android limita bastante o quanto de memória seu aplicativo pode usar, para não acontecer de um único aplicativo usar todos os recursos do sistema, é bem fácil dar erro no programa se você ficar carregando imagens sem liberar a memória quando não tiver usando mais elas.
E um caso especÃfico em que se tem que tomar muito cuidado com o uso de recursos é o desenvolvimento de jogos, pois neste caso você precisa se preocupar com o Garbage Collector, ou melhor dizendo, precisa evitar que ele seja chamado com frequência, e para isso você precisa é evitar alocações, e um dos grandes vilões neste caso é o uso de strings, pois o que geralmente não faz diferença para um programa normal faz muita diferença para um algoritmo que deveria ser executado 60 vezes por segundo, pois o simples fato de concatenar strings já gera uma nova alocação afinal strings são imutáveis, o que pode gerar centenas de objetos por segundo que vão precisar ser liberados pelo GC, o que em um momento qualquer pode gerar uma pequena pausa em seu programa, o que não seria percebido se não fosse o caso dele precisar rodar tão rápido
Apesar de todas as explicações anteriores, vou tentar acrescentar algo (rs).
Quando você usa um programa qualquer o que mais te irrita? Layout feito, ter recursos básicos ou ser lento?
Bem se o programa é útil e faz o que promete, claro que a lentidão é o que pode fazer você desistir de usá-lo e procurar outro, mas se for rápido, até rodando em DOS você irá usar.
Com base nisso e tudo que já foi explicado, imagina que um micro hoje é Top de linha, mas em alguns meses e após o uso, já não será, pois vai acumulando lixo de instalações e desinstalações, os programas vão ficando cada vez mais exigentes e principalmente cada vez mais serviços e softwares estarão rodando [Ô]simultaneamente[Ô]. Assim se cada desenvolvedor negligencia seu desenvolvimento e desperdiça recursos e memória, pois o micro é top, logo o micro será uma [Ô]Carroça[Ô].
Se formos passar um pende fino em nossos códigos, veremos tantas coisas que podem ser otimizadas, e isso faz muita diferença no final. Uma simples rotina que faz um ou dois cálculos desnecessários, um método para pegar hora executado mais de uma vez, ou usar recursos de forma errada, somados irão comprometer muito o desempenho de seu programa, principalmente se houver vários outros softwares em execução.
Veja um caso simples: Concatenar string ou usar o StringBuilder. O ganho de performance do segundo é absurdo, e como ele tem várias outras coisas básicas em programação.
Espero ter ajudado um pouquinho.
Quando você usa um programa qualquer o que mais te irrita? Layout feito, ter recursos básicos ou ser lento?
Bem se o programa é útil e faz o que promete, claro que a lentidão é o que pode fazer você desistir de usá-lo e procurar outro, mas se for rápido, até rodando em DOS você irá usar.
Com base nisso e tudo que já foi explicado, imagina que um micro hoje é Top de linha, mas em alguns meses e após o uso, já não será, pois vai acumulando lixo de instalações e desinstalações, os programas vão ficando cada vez mais exigentes e principalmente cada vez mais serviços e softwares estarão rodando [Ô]simultaneamente[Ô]. Assim se cada desenvolvedor negligencia seu desenvolvimento e desperdiça recursos e memória, pois o micro é top, logo o micro será uma [Ô]Carroça[Ô].
Se formos passar um pende fino em nossos códigos, veremos tantas coisas que podem ser otimizadas, e isso faz muita diferença no final. Uma simples rotina que faz um ou dois cálculos desnecessários, um método para pegar hora executado mais de uma vez, ou usar recursos de forma errada, somados irão comprometer muito o desempenho de seu programa, principalmente se houver vários outros softwares em execução.
Veja um caso simples: Concatenar string ou usar o StringBuilder. O ganho de performance do segundo é absurdo, e como ele tem várias outras coisas básicas em programação.
Espero ter ajudado um pouquinho.
Citação:: Pense em um Facebook, por exemplo. Imagine quantos usuários estão nesse exato momento fazendo dezenas de requisições por conteúdo......
Só esse exemplo já diz tudo, sem fala nas NFe's também,
definitivamente economizar recursos deve ser um hábito essencial
a todo programador.
Tópico encerrado , respostas não são mais permitidas