"Vale a pena" precisa de contexto, como o mais simples de escrever, ler e manter, e o quanto mais rápido torna algo para o usuário muito mais responsivo e interativo, exigindo menos tempo para esperar.
Economizar alguns centavos para comprar uma lata de refrigerante não me fará muito bem se eu tiver que percorrer uma distância para economizar esses centavos, principalmente porque raramente tomo refrigerante hoje em dia. Economizar alguns centavos por lata na compra de um milhão de latas de refrigerante pode ser um grande negócio.
Enquanto isso, economizo alguns centavos quando duas pessoas estão ao meu lado e uma oferece exatamente a mesma coisa por algumas mais baratas e a outra não, e eu escolho a mais cara porque gosto mais do chapéu delas, parece um caso tolo de pessimização.
O que costumo encontrar pessoas chamando de "micro-otimizações" parece curiosamente desprovido de medições, contexto e discussão do usuário, quando deveriam existir os três para considerar essas otimizações, caso não sejam triviais. Para mim, uma micro otimização adequada hoje em dia está relacionada a coisas como layouts de memória e padrões de acesso e, embora possam parecer "micro" em foco, eles não são micro em efeito.
Consegui, há pouco tempo, reduzir uma operação de 24 segundos para 25 milissegundos (cerca de 960 vezes mais rápido), com saídas idênticas (protegidas por testes automatizados), sem alteração na complexidade algorítmica, para a cobertura volumétrica de difusão de calor, através de "micro-otimizações" (a maior das quais veio de uma alteração no layout da memória, que reduziu para cerca de 2 segundos, o restante foram coisas como SIMD e análises adicionais de falhas de cache no VTune e algum rearranjo adicional do layout da memória).
Wolfire explica a técnica aqui e lutou com o tempo necessário:
http://blog.wolfire.com/2009/11/volumetric-heat-diffusion-skinning/
Minha implementação conseguiu fazer isso em milissegundos enquanto ele lutava para reduzi-lo a menos de um minuto:
Depois que eu "otimizei" o micro de 24 segundos para 25ms, isso mudou o fluxo de trabalho. Agora, os artistas podem mudar suas plataformas em tempo real a mais de 30 FPS sem esperar 24 segundos cada vez que fazem pequenas alterações em suas plataformas. E isso realmente mudou todo o design do meu software, já que eu não precisava mais da barra de progresso e coisas desse tipo, tudo se tornou interativo. Portanto, isso pode ser uma "micro-otimização" no sentido de que todas as melhorias ocorreram sem nenhuma melhoria na complexidade algorítmica, mas foi uma "mega-otimização" em vigor que tornou o que antes era um processo doloroso e não interativo. para um interativo em tempo real que mudou completamente a maneira como os usuários trabalhavam.
Medição, Requisitos de Usuário Final, Contexto
Gostei muito do comentário de Robert aqui e talvez não tenha conseguido expressar o que queria:
Bem, vamos lá. Ninguém vai argumentar que esse tipo de mudança não "vale a pena". Você conseguiu demonstrar um benefício tangível; muitas das chamadas micro-otimizações não podem.
Apesar de trabalhar em um campo muito crítico para o desempenho, com requisitos frequentemente em tempo real, é o único momento em que considero qualquer micro-otimização que exija que eu saia do meu caminho.
E eu enfatizaria não apenas as medições, mas também o lado do usuário. Sou uma pessoa estranha porque cheguei ao meu campo atual (e anteriormente gamedev) como usuário / fã primeiro, desenvolvedor segundo. Portanto, nunca fiquei tão empolgado com as coisas usuais que empolgam os programadores como resolver quebra-cabeças técnicos; Achei um fardo para eles, mas aguentaria com eles o sonho do usuário final que compartilhei com outros usuários. Mas isso me ajudou a garantir que, se eu estivesse otimizando alguma coisa, teria um impacto real nos usuários com benefícios reais. É minha salvaguarda contra a otimização micro sem rumo.
Isso é realmente tão importante quanto o criador de perfil na minha opinião, porque eu tive colegas que fizeram coisas como otimizar a subdivisão de um cubo em um bilhão de facetas apenas para engasgar com modelos de produção do mundo real, como personagens e veículos. O resultado foi impressionante em algum sentido de "demonstração tecnológica", mas quase inútil para os usuários reais, porque eles estavam criando perfis, medindo e comparando casos que não estavam alinhados com os casos de uso do mundo real. Portanto, é muito importante entender primeiro o que é importante para os usuários, aprendendo a pensar e usar o software como um ou colaborando com eles (idealmente ambos, mas pelo menos colaborando com eles).