eu estou familiarizado com otimização. eu vejo os programas de outras pessoas com um conjunto diferente de olhos - eis a minha opinião:
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.
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.
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".
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).
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?
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).