Normalmente, a microoptimização é considerada não vale a pena com a seguinte explicação: pode acelerar o programa em menos de um por cento, mas ninguém se importa com esse pequeno impulso - isso é uma mudança muito pequena para ser notada.
Além disso, pode haver algum manipulador de eventos que dispara mil vezes por segundo e sai muito rápido - antes de ser disparado novamente. Ninguém se importa com o quão rápido é - tornando-o mais rápido não pode ser notado, porque já "é tão rápido quanto pode ser observado".
No entanto, em dispositivos móveis, o consumo de energia é um fator importante. O mesmo manipulador de eventos otimizado para executar dez por cento mais rápido resultará em menos energia consumida e maior duração da bateria e um dispositivo operacional mais longo.
Qual é a precisão do último julgamento sobre dispositivos móveis? Existem exemplos da vida real que confirmam ou refutam isso?
fonte
Respostas:
Vale a pena se as medições dizem que vale a pena. Para dispositivos móveis, bem como supercomputadores.
EDIT: Pouco fora do tópico, mas sobre o seu exemplo. Se o evento for disparado muitas vezes, você terá um problema de concepção, e resolver esse problema é o verdadeiro negócio. Não o torne menos visível através da micro otimização.
Você pode executar um teste no retorno de chamada, por exemplo, para descartar chamadas muito freqüentes ou retrabalhar da maneira como o retorno de chamada é chamado.
Em geral, é uma prática recomendada anexar retorno de chamada a "eventos contínuos". Com isso, quero dizer eventos que não são acionados de uma só vez, mas que são acionados em ações que duram ao longo do tempo.
Rolar uma página ou um controle deslizante, por exemplo, são eventos contínuos.
Você nunca sabe quantas vezes esses eventos serão acionados. Se eles forem acionados com rapidez suficiente, seu aplicativo ficará lento e, se forem acionados muitas vezes, você terá uma enorme carga de CPU por nada, potencialmente tornando seu aplicativo também lento.
fonte
É tão preciso quanto as medições reais no dispositivo real que realmente indicam que a otimização real realmente ajudará.
Suposições e julgamentos são inúteis.
As medições têm valor.
Toda otimização (incluindo "microoptimização", seja o que for) é uma perda de tempo até que haja uma medição real que indique um problema real em que o código realmente não atende a algum requisito (velocidade, memória, energia ou latência da rede ou qualquer outra coisa) )
fonte
(Supondo que a velocidade seja seu principal problema.) Todo mundo está certo.
Exceto - a medição não indica o que otimizar.
A medição informará que você precisa otimizar.
A medição informará quanto você economizou ao otimizar.
A medição não indica o que otimizar.
Essa técnica lhe dirá o que otimizar.
fonte
eu estou familiarizado com otimização. eu vejo os programas de outras pessoas com um conjunto diferente de olhos - eis a minha opinião:
o engraçado é que uma dessas mudanças leva a 99%. dez dessas mudanças tornam o programa notavelmente mais rápido. para muitos engenheiros, as mudanças na abordagem de escrever um programa podem fazer com que um programa seja executado várias vezes mais rápido. simplesmente estar ciente da eficiência e escrever dessa maneira pode tornar seu programa várias vezes mais rápido sem muito trabalho adicional. tais ganhos não são micro-otimizações.
nota: nunca estou sugerindo otimizações contextualmente inovadoras nesta discussão.
e provavelmente já está fazendo mais trabalho do que o necessário, pois 1kHz é muito maior do que muitos casos exigem. qual é a fonte desse manipulador de eventos e quais são seus efeitos? se estiver simplesmente atualizando a interface do usuário e os eventos puderem ser coletados e combinados, o envio de 1kHz certamente será um exagero (muito mais que 1% - mais ou menos como 25x). para um sistema que possui várias fontes e é transmitido em série, 1kHz pode não ser rápido o suficiente (por exemplo, MIDI).
com base nos programas que eu vi, não há muitas pessoas considerando (ou preocupadas com) essas otimizações, mesmo que a mudança de sua abordagem para escrever programas possa gerar ganhos incríveis (> 10x ou muito mais rápido). muitos que eu já vi (no lado do desenvolvimento de aplicativos) simplesmente escrevem e adotam uma abordagem de cima para baixo ou "granizo" quando (/ se) os problemas de desempenho os alcançam. Da mesma forma, muitos nem sequer reservam um tempo para criar um perfil até essa ocorrência. a essa altura, o ruído de tantas ineficiências compostas dificulta a obtenção de informações úteis de um criador de perfil. exemplos da abordagem granizo-maria seriam otimizar as áreas erradas (com ou sem procurar áreas problemáticas) ou apenas lançar mais núcleos nas áreas problemáticas; isso acontece, em vez de corrigir as ineficiências existentes.
para o programa típico existente (entre os programas móveis que eu já vi), a otimização não era uma grande preocupação quando escrita. então "sim" valem o tempo (no caso típico), desde que estejam no orçamento e sejam uma prioridade. nesse caso, essas dez alterações que tornam o programa notavelmente mais rápido provavelmente podem ser executadas em poucas horas e menos de um dia.
"escreva preguiçosamente e faça um perfil em retrospecto", pois a única ação para melhorar um programa é uma péssima idéia: dedicar um tempo para aprender a escrever um programa eficiente (como está escrito, não gravando juntos no final) é o superior abordagem (imo); use os algoritmos certos, proíba cópias desnecessárias, alocações, cálculos (+ muitas, muitas outras categorias). é claro, analisar o desempenho em retrospecto tem seus méritos, mas se você escrever o programa para ser eficiente desde o início, terá um novo nível de eficiência, porque aprenderá muito e considerará e avaliará a execução de várias perspectivas.
a outra coisa é que os programas devem (com freqüência) ser gravados para reutilização; um programa mal gravado introduzirá alterações que podem interromper os programas dos clientes quando as ineficiências forem removidas (ou permanecer ineficientes para evitar a interrupção dos programas existentes).
Um grande benefício de considerá-lo quando você escreve é que você tem uma idéia muito clara de como o programa funcionará (embora não seja uma imagem completa), você pode usar essas informações para ajudar no design das interfaces e como ele armazena seus dados . a verdade é que um engenheiro pode implementar algo várias vezes (por exemplo,> 10x) mais rápido que as soluções padrão "tamanho único" fornecidas com o sistema operacional.
finalmente, também vale a pena além dos dispositivos móveis. existem muitos programas ineficientes por aí, escritos com a mentalidade de que o hardware será mais rápido em dois anos (lógica frequente, mesmo para programas escritos hoje!). enquanto isso não está incorreto , é otimista demais. também, a paralelização tem um objetivo, mas é a "solução padrão" errada para muitos programas. muitos desses programas existentes podem ser melhorados com a remoção das ineficiências existentes.
então ... normalmente há uma tonelada desses casos de 1%, 2%, 7% (e muito pior) no mundo real. corrigi-los ou (mais importante) não escrever / expor em primeiro lugar pode trazer grandes benefícios. muitos desses casos podem ser facilmente localizados e corrigidos (desde que o engenheiro tenha alguma experiência com isso). No entanto, pode ser realmente difícil corrigir e testar novamente após o fato. se um programa é ideal, será idealmente escrito dessa maneira desde o início.
como usuário final, é irritante esperar continuamente por programas lentos e jogar duas vezes o hardware em problemas criados por programas lentos / ineficientes: P: "o que você fará agora que possui o dobro dos núcleos e o dobro da memória?" R: "recupere a capacidade de resposta e a produtividade que eu tinha antes de atualizar meu software - é isso". bastante imprudente do desenvolvedor (imho).
fonte
A razão pela qual você não deve se preocupar com micro otimizações é que elas são micro otimizações. Você deve ter uma visão geral e, em vez de perder seu tempo com micro otimizações, encontre razões para melhorias reais .
Minha regra geral é que qualquer código que foi escrito sem levar em consideração a velocidade, mas também não totalmente estúpido, pode ser feito dez vezes mais rápido com muitos esforços. 10% através de micro-otimizações não é algo que eu me preocuparia. Tenho certeza de que você pode economizar muito mais do que isso, com menos esforço.
Por outro lado, em produtos comerciais nos últimos anos, a "otimização" para mim consistiu principalmente em encontrar código que desperdiçou tempo, e não desperdiçá-lo. Mais falta de pessimização do que otimização.
(Por outro lado, algumas pessoas pensam que a otimização prematura é ruim; portanto, se existe uma maneira de A fazer algo e uma maneira B que é menos eficiente, elas escolhem B porque A é "otimização prematura". Algumas pessoas são simplesmente estúpidas).
fonte