Falou bonito hein Rafael, hehe.

Agora sério, Knuth só não falou 100% para ser mais humilde.

Refactoring não somente em deixar o modelo implementado mais legível como também realizar algumas otimizações no código (partindo-se do fato de que já se foi levantando através de ferramentas adequadas quais os possíveis bottlenecks existentes e os pontos a serem atacados já foram demarcados).

No início do projeto ainda se tem dúvidas a respeito do negócio ao qual o software vai atender, algo que vai se tornando maduro com o desenvolvimento do projeto. Portanto, é muito difícil prematuramente elocubrar todos os possíveis problemas de performance e necessidades de otimização que o software vai enfrentar durante seu desenvolvimento.

Isso não tira o fato de que a arquitetura concebida para suportar o desenvolvimento das funcionalidades do sistema não deva ser flexível o suficiente para permitir tais otimizações durante o desenrolar do projeto. Afinal, ela deve ser robusta, manutenível e flexível para permitir a implementação de novas features e também a fácil correção de problemas, como os de necessidade de otimização citados aqui. Logo, a arquitetura deve ser orientada aos requisitos funcionais mas dar o devido suporte aos requisitos não-funcionais.

Ronie, eu assino embaixo, sem medição otimizar é um tiro no escuro mesmo.

Aumentar a performance de um trecho de código geralmente implica em aumentar sua complexidade e diminuir sua legibilidade (mas nem sempre), para não falar do tempo que se perde, então é algo que deve ser feito apenas com a certeza de sua necessidade.

Agora eu confesso que tiro o corpo fora da discussão quando se fala de desenvolvimento de jogos por exemplo, não tenho experiência nesta área para dar meus pitacos, agora no mundo de aplicações corporativas o conselho do Knuth é lei.

Ronie, eu assino embaixo, sem medição otimizar é um tiro no escuro mesmo.

Aumentar a performance de um trecho de código geralmente implica em aumentar sua complexidade e diminuir sua legibilidade (mas nem sempre), para não falar do tempo que se perde, então é algo que deve ser feito apenas com a certeza de sua necessidade.

Agora eu confesso que tiro o corpo fora da discussão quando se fala de desenvolvimento de jogos por exemplo, não tenho experiência nesta área para dar meus pitacos, agora no mundo de aplicações corporativas o conselho do Knuth é lei.

A maior parte das vezes que tive problemas com performance foram por violação ao item 2

Concordo que não se pode deixar a performance completamente de lado. Mas a única maneira de evitar “achismos” nessa parte é medir. Sem medição, pensar em perfomance (antes ou depois) e completamente pointless.

Será realmente que TODA otimização feita no início de um projeto de software é ruim e pode ser prejudicial? Miguel Galves discute este aspecto e tenta mostrar que em alguns casos, não só não é prejudicial como é necessária.