Promovendo um período de tempo em que todos possam experimentar alguma idéia para tornar o software mais rápido?

Às vezes, truques de desempenho de software são encontrados em uma pesquisa metodológica e completa. Às vezes, exige pensamento e coragem divergentes para tentar idéias malucas. Às vezes, uma idéia é apenas o começo que precisa ser seguida com muito trabalho duro.

Como promover um período em que todos possam experimentar idéias diferentes para melhorar o desempenho do software em que estamos trabalhando? Todos na equipe têm pelo menos vários meses de experiência com o software e são muito bons nisso.

Você concorda que o pensamento divergente ajudará a encontrar maneiras de melhorar o desempenho do software? Por quê? Por que não?

Quais técnicas nos permitirão experimentar rapidamente uma idéia de otimização? A velocidade rápida de codificação é necessária para obter bons resultados com o teste?

Finalmente, quanto tempo deve ser alocado para garantir bons resultados sem criar a possibilidade de folga?

A experimentação é necessária para provar que "existe uma maneira mais rápida de fazer alguma coisa"? (Adicionado em 06-06-2011)

Relacionado:

• Quais são suas estratégias para melhorar o nível de sua equipe de maneira inteligente?
• Quando os hacks de código se tornam ruins?

( Somente para fins de recompensa -2011/06/07, o tamanho da equipe é de 2 a 4 desenvolvedores, sem controle de qualidade dedicado. Todo o código, teste de unidade e teste de desempenho realizado pelos desenvolvedores. Devido à natureza do projeto, o resultado do criador de perfil é útil para mostrar tempo de execução proporcional, mesmo que não revele um único gargalo.)

Sua melhor aposta é identificar os pontos de acesso com um criador de perfil e - em equipe - discutir como consertar os pontos de acesso.

Você deve ser capaz de medir e documentar a melhoria (para que não seja apenas um palpite) e fazê-lo em equipe garante que as pessoas saibam o que está sendo corrigido e como.

Tendo os programadores hackeando loucamente a base de código tentando idéias, você não tem controle sobre o que está acontecendo e se funciona.

Os programadores tendem a ser inteligentes e criativos (já que esses são pré-requisitos para ser bom em programação), por isso é sempre bom deixá-los experimentar uma ampla gama de idéias ao tentar resolver problemas. No entanto, há duas coisas que é importante lembrar ao tentar melhorar o desempenho (suponho que com "desempenho" você queira reduzir a velocidade de execução):

• Otimizações algorítmicas tendem a funcionar muito melhor do que qualquer outra coisa. Como um exemplo trivial, o que você fizer com sua implementação de bolhas, com números suficientes, uma implementação extremamente lenta do quicksort será mais rápida.
• Fazer qualquer coisa relacionada ao desempenho é completamente sem sentido, a menos que você avalie (perfil) e baseie o que fizer nos resultados.

Meu ponto principal é que é importante garantir que você esteja na mesma página com todos sobre essas coisas antes de iniciar um período de experimentação selvagem . É sempre uma pena descobrir depois que seus colegas de trabalho menos experientes estavam tentando coisas que nunca funcionariam (e você poderia ter dito isso a eles com antecedência).

Infelizmente, não posso falar por experiência própria. Mas ouvi dizer que Atlassian tem um único dia em que os funcionários podem fazer suas próprias coisas, o que quiserem, e apresentar suas idéias em uma espécie de ambiente de festa. Acabou bem para eles, aparentemente. Mas eu teria que concordar com Andersen e dizer que, quando se trata de desempenho, idéias criativas e prontas para uso são menos importantes que o perfil de quais processos levam mais tempo. Talvez, depois de criar um perfil do seu sistema, você possa dar a todos um dia ideias de como ajudar a acelerar seções importantes do processo. Depois de apresentarem suas idéias, você pode escolher quais tentar.

Uma prática bem-sucedida que fizemos em algumas das minhas equipes anteriores foi ter o conceito de Deep Dives. Algumas pessoas se reuniam em uma sala de conferências, determinavam algum cenário do usuário e apenas começavam a percorrer o código ou a olhar para os logs do criador de perfil. Em alguns casos, os dados mostraram claramente gargalos que nos permitiram convencer os céticos de que realmente havia problemas de desempenho em seu próprio código! Para obter sucesso, houve alguns princípios fundamentais que seguimos:

1. Tente se concentrar em cenários críticos ou caminhos de código nos quais há suspeita de gargalos. Não perca tempo otimizando coisas que não precisam ser otimizadas (se não estiverem quebradas ...)
2. Mantenha o grupo pequeno e focado nas pessoas que conhecem melhor o código. Não se esqueça de incluir o testador e o gerente de programa do recurso - eles têm informações importantes e podem se beneficiar da participação ou da coleta de informações sobre como eles podem testar melhor.
3. Inicie a sessão solicitando que o proprietário da área forneça um diagrama de nível de bloco arquitetônico de alto nível e uma visão geral da área. Quais são os principais componentes e descreva brevemente o que eles fazem. Você ficará surpreso quantas vezes o diagrama de blocos não refletiu a realidade depois que inserimos o código. (Citação real: "Eu não sabia que ainda usamos esse componente. Pensei que tivéssemos nos livrado disso anos atrás!")
4. Espere encontrar bugs funcionais, bem como problemas de desempenho. É uma coisa boa. Além disso, espere que, às vezes, você não encontre nada significativo. Isso pode ser uma coisa boa também.
5. Espere ter várias sessões longas. Estas são reuniões de trabalho. Fique à vontade e trabalhe com isso. Você realiza muito mais quando todos podem colaborar para trechos estendidos.
6. Faça anotações, boas anotações. Se você usar um banco de dados de rastreamento de defeitos, considere abrir problemas imediatamente para acompanhar, mesmo que sejam de baixa prioridade.

Evite que a equipe inteira participe de um "empurrão de desempenho". Geralmente, esses resultados não têm os resultados esperados pela administração pelos motivos mencionados por Thorbjørn Ravn Andersen em outra resposta. Você obterá grandes ganhos em algumas áreas, regressões em outras áreas em que as pessoas não estão familiarizadas, e é difícil prever / acompanhar quantos ganhos você deve obter para dizer "está feito". É uma conversa desafiadora para se ter com a gerência.

A razão pela qual você pode precisar melhorar a velocidade do seu software é se algo nele estiver visivelmente lento. Se não for esse o caso, otimizar é uma perda de tempo. Mas se algo estiver lento, faça a tarefa.

... E para executar a tarefa, há duas etapas nesta ordem:

1. Veja se a função que está executando a tarefa está gravada com eficiência. Possui um algoritmo bom ou ruim? É acessar um banco de dados de forma eficiente. É um loop de 100 vezes quando uma vez pode fazer? Freqüentemente, a simples inspeção do código pode encontrar o único obstáculo e não apenas corrigi-lo, mas torná-lo um programador melhor ao mesmo tempo.

2. Não gaste mais de uma hora no número 1. Se não conseguir encontrar o problema em uma hora, use um criador de perfil para encontrar o local em questão. Depois de conhecer o ponto do problema, você pode voltar ao número 1 e fazer isso novamente, buscando a melhor maneira de melhorar o código que você identificou.

Em geral (**), você não obtém melhor desempenho por experimentação.

Você entende

• Saber como criar um design simples e eficiente para começar. Se você errar esta parte, a experimentação não fará muita diferença. Por exemplo, saber como usar um gerador de código é uma abordagem de design vencedora.

• Saber ajustar o software localizando as atividades que são a) caras em uma porcentagem eb) substituíveis por algo melhor. Todo mundo sabe que você deve "usar um criador de perfil", mas isso não é suficiente.

Verifique esta resposta para sua outra pergunta.

** As exceções podem ser um código dependente de hardware, como renderização gráfica, pipeline do processador ou comportamento CUDA, ou experimentar protocolos de rede ou banco de dados, nos quais você só precisa se familiarizar com a melhor maneira de usá-lo.

ADICIONADO: Há algo que muitos programadores de grandes sistemas acham surpreendente. É que, em grandes programas perfeitamente bem construídos, pode haver problemas grandes e invisíveis de desempenho, e os criadores de perfil não conseguem encontrá-los porque não estão localizados nas rotinas. Eles fazem parte da estrutura geral do programa, mesmo que o programa possa ser realizado da melhor maneira possível.

Apenas para dar um exemplo concreto, aqui está um programa com código fonte (em C ++) que faz um trabalho. Ele é destilado de um programa C em que eu trabalhei.

Ele faz o que se pretendia fazer, mas que fração de seu tempo não é realmente necessária? Quanto poderia ser acelerado?

Bem, na primeira versão do programa, algo perfeitamente razoável e não-local (invisível para um criador de perfil) estava levando 33,3% do tempo. Quando foi substituído, esse tempo foi economizado e essa foi a segunda versão do programa.

Na segunda versão do programa, outra coisa (invisível para qualquer criador de perfil) que pudesse ser removida consumia 16,7% do tempo. Removê-lo levou à versão 3.

Na versão 3, 13% foram removidos. Do que restou, 66% foram removidos. Do que restou depois disso, 61% foram removidos!

Finalmente, do que restou depois disso, 98% foram removidos!

Então, qual é o quadro geral? De cada 1000 ciclos gastos pelo programa original, quantos foram removidos? 998!

Todo programa é diferente, mas todo programa grande, na minha experiência, tem uma série de problemas que os criadores de perfil não encontrarão, que amostragem manual terá e que, se os programadores realmente estiverem buscando o desempenho máximo, poderão ser removidos para grandes acelerações.